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requirements that can be applied across all surface combatants for the Surface Warfare and 
Maritime Interception Operations missions. The project applied a systems engineering process 
consisting of a needs analysis, functional analysis, and modeling and cost analysis. The needs 
analysis defined key user objectives and needs and identified threats to Navy platforms. The 
functional analysis included the core tasks of requirements definition and enterprise architecture. 
The modeling and cost analysis task verified the C2 system architecture and evaluated possible 
training course hour savings. The project found that the definition of a common set of C2 system 
requirements and system architecture is feasible and does provide possible life cycle cost savings 
to the Navy. In order to fully evaluate a proposed common C2 system, further work will be 
required, expanding the analysis to other missions and assessing the cost impacts of a common 
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EXECUTIVE SUMMARY 


The Naval Surface Warfare Center (NSWC) capstone team project is focused on 
eliminating redundancies in the U.S. Navy’s development and deployment of Command and 
Control (C2) systems across multiple platforms, which could result in potential cost savings. 
Senior leaders across the Acquisition community acknowledged deficiencies of acquisition effort 
stemming from the fact that various ship platforms utilize different C2 systems to accomplish 
similar ship functions. This redundancy results in potentially unnecessary cost to maintain 
different configurations, training curricula, logistics support, and upgrade plans. This capstone 
project develops a common set of C2 functional requirements and a C2 enterprise architecture 
applicable to Guided Missile Cruiser, Destroyer and Frigate class platforms. 

The purpose of this project is to test the assertion that a common architecture will result 
in cost savings to the Navy, and also to demonstrate a methodology to develop a common 
architecture. Acknowledging that development of a complete surface combatant C2 architecture 
is a complex and resource intensive task, a method is needed to bound the scope of the problem 
for the capstone project. For this reason, the project focuses on two representative mission 
threads (surface warfare and maritime interception operations) to bound the requirements and 
architecture development, with the intent that the same processes in this project could be scaled 
to other, larger applications. 

This project uses a tailored system engineering process based upon the Defense 
Acquisition University systems engineering process model to develop a common architecture. 
The systems engineering emphasis is organized into three phases: Needs Analysis, Functional 
Analysis, and Modeling and Simulation. The Needs Analysis phase identifies the aspects of C2 
that are of greatest concern and interest to the U.S. Navy. These include supporting the entire 
surface warfare kill chain, positive identification of contacts utilizing all sensors, integration of 
off-board sensors into the tactical picture, supporting automated identification, supporting 
distributed weapons control, real-time sensor netting and preplanned responses, and employing 
non-kinetic and non-damaging effects. Additionally, a threat assessment is conducted during this 
phase to analyze the range of surface threats likely to be presented to a C2 system during 
operations. 
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Mission system functional requirements are developed during the Functional Analysis 
phase based on infonnation contained within the Navy Tactical Task List, Navy Surface Warfare 
Manual, various Joint Publications, stakeholder interviews, and also derived from mission thread 
analysis. A significant aspect of the requirements effort is that the higher level joint publications 
are used to tailor the requirements to the mission without targeting a specific, existing C2 
system. A value system design is created to describe the objectives, measures of effectiveness 
and perfonnance, and threshold values for each of the developed requirements. Architecture 
products are developed for the high-level operational concept (OV-1), operational activity model 
(OV-5), and systems functionality description (SV-4). 

The Modeling and Analysis phase is used to validate the architecture model and to 
examine a methodology to evaluate potential cost savings to the Navy. The simulation capability 
of CORE, a commercially available systems engineering and design software tool, and Colored 
Petri Nets (CPN) are used to validate the consistency and execution of the architecture. The 
training curricula for Aegis and Ship Self Defense System (SSDS) are used as a comparison 
study to validate the assumption that cost savings can be achieved by developing a common 
enterprise architecture. Common training courses between the two systems and the hours 
required to complete the training for each system are mapped to the functions defined in the 
Functional Analysis to ensure that the training covered the relevant C2 functions. Cost savings 
in the form of man-hours can then be identified in areas of potential training redundancy. 

The project created a list of C2 system requirements and a validated common functional 
architecture that could be applied across multiple platforms. The project also demonstrated that 
a common system architecture could result in reduced training costs throughout the lifecycle of 
the system. Thus, the report recommends that the Navy acquisition community pursue 
opportunities to design and develop common system architectures as cost savings initiatives. 


xiv 



I. INTRODUCTION 


A. PROBLEM STATEMENT 

Surface navy ship C2 systems are the means by which the commander’s intent is made 
clear, allowing the crew to know what is required to meet the mission. C2 systems have evolved 
from 19th century signal flags to modern computerized command and decision systems 
[Edwards, 2008]. The 21st century US Navy defines C2 as “The exercise of authority and 
direction by a properly designated commander over assigned and attached forces in the 
accomplishment of the mission. Command and control functions are performed through an 
arrangement of personnel, equipment, communications, facilities, and procedures employed by a 
commander in planning, directing, coordinating, and controlling forces and operations in the 
accomplishment of the mission” [Office of the Chief of Naval Operations, 2007, Glossary-1]. 
An important aspect to draw from this definition is that the Command and Control system 
includes people, hardware and software; all of which are part of, or support, the authority and 
direction process. 

Across the Surface Navy Enterprise, each new ship class implements a new C2 design for 
the combat system with a unique set of system requirements and associated architecture. The 
U.S. Navy currently develops and deploys multiple major surface C2 systems: the Aegis 
Command and Decision system on Aegis cruisers and destroyers, the Ship Self Defense System 
on aircraft carriers and large deck amphibious ships, and the Total Ship Computing Environment 
currently planned for DDG-1000. Each of these unique C2 systems has separate design and 
development efforts, training pipelines, support requirements, and upgrade activities. Life cycle 
costs associated with maintaining distinct development, test, and support activities for each C2 
system are very high. Capability upgrades to these systems are costly because systems are 
complex, tightly coupled, and tied to specific vendors who are protected against competition by 
contractual barriers and large capital requirements. Upgrades also take too long to reach the 
fleet, possibly being obsolete by the time they get there [Edwards, 2008]. System operators who 
are trained and experienced in one C2 system typically are not qualified to operate the others, 
which limits the Navy’s flexibility in manning platforms. 

To address these problems, the surface navy acquisition community has assumed that 
there is potential for significant cost savings, faster introduction of war fighting capability, and 
improvements to surface fleet readiness if a common set of core C2 components were developed 
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for all surface combatants [Benedict, 2008]. One approach to achieve a core set of C2 
components is to define a common C2 architecture following systems engineering principles. 

In alignment with the surface navy’s strategy, this capstone project focuses on the 
development of a common set of requirements and C2 architecture, to support two specific 
mission threads for implementation on multiple surface ship platforms. As a metric for 
affordability, the project will evaluate “school house” training hours. Specifically, will a 
common C2 architecture help to reduce the training hours required for the operator? 

B. PROJECT DESCRIPTION 

In an effort to maximize combat effectiveness, surface combatant platforms use 
command and control to coordinate employment of the ship’s sensors and weapons, to make 
sense of the tactical situation, and to plan and coordinate their activities with those of other units 
in the area of operations. Department of Defense Architecture Framework (DoDAF) products 
provide a DoD-accepted approach for describing an architecture capable of performing these C2 
functions, and were used to define and develop an enterprise-level C2 architecture that is 
independent of existing systems or platforms. This architecture was developed to support 
functionality normally performed by combatants normally assigned surface warfare as a primary 
mission area, such as cruisers, destroyers and frigates. The expectation is that the concepts and 
processes developed in this project are scalable to broader surface platform applications. 

The DoDAF products are based upon two representative mission threads and associated 
C2 functionality. Two mission threads were selected for this project to capture the desires and 
needs of the stakeholders and to scope the focus of the project into manageable overlapping 
areas. The mission threads assessed were: conduct surface warfare (SUW) operations and 
conduct maritime interception operations (MIO). The selected mission threads cover both 
combat and non-combat conditions and represent two unique roles of many missions that a C2 
system should be capable of perfonning in a specified area of operation. The conduct SUW 
thread includes the ability of the C2 system to process and assess sensor contacts, track, identify, 
and report possible targets as well as support engagement decisions while maintaining and 
supporting the Common Tactical Picture. The conduct MIO thread includes the ability of the C2 
system to exchange information during a MIO event in order to support battlespace awareness 
and decision-making. In short, SUW and MIO were detennined to be broad enough yet focused 
enough to represent the development of a common C2 architecture. 
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A set of enterprise C2 requirements was then developed, based on the SUW and MIO 
mission threads. The common set of C2 requirements and mission threads were instrumental in 
the development of an enterprise-level C2 architecture. Several of the architecture descriptions 
are presented as DoDAF products. Finally, a cost analysis, in terms of training hours, was 
performed to establish avenues in which the US Navy may realize savings by using a common 
set of C2 requirements and architecture. This report documents the methodology and the process 
used to identify the superset of requirements, providing a traceable and repeatable means for 
developing other C2 architectures for additional mission threads. 


C. SYSTEMS ENGINEERING PROCESS 

A tailored system engineering process illustrated in Figure 1 was employed to establish 
the C2 enterprise architecture and requirements. This process is an adaptation of the systems 
engineering process published in System Engineering Fundamentals [Defense Acquisition 
University, 2001]. 



Customer' 
Needs 


Needs Analysis 


Stakeholder 

Analysis 


□ Stakeholder Values & Metrics 

□ Threat Parameters 

□ Representative Mission Threads 






Figure 1: NSWC Tailored System Engineering Process 


The Systems Engineering (SE) process model for this project consists of three phases: Needs 
Analysis, Functional Analysis, and Modeling and Analysis. Each successive phase builds upon 
the previous phase. 


3 








































The tailored process consists of three iterative phases which began with the Needs 
Analysis phase. This phase focused on research to understand the stakeholders’ needs and 
expectations, and also to gain more insight into the problem statement. This phase also included 
investigation of the two mission threads and threats against the platfonns. These mission threads 
and threats were analyzed in order to understand the operational needs and objectives of 
command and control. The mission threads also provided project context for the definition of 
C2. (For example, the mission threads assumed that the C2 system included human, hardware, 
and software components.) Stakeholder Analysis helped to identify system functionality. 
Mission thread definition helped identify additional functionality and provided context for the 
system. The threat assessment provided platfonn threat infonnation. The information gathered 
within the Needs Analysis phase served as the input for the Functional Analysis phase and was 
used as the basis of the C2 architecture and requirements development. 

In the Functional Analysis phase, the system-level requirements and the functional 
architecture for the C2 aspects of the platform were defined. The information collected in the 
Needs Analysis phase (e.g. needs, threats, functionality) was documented as requirement “shall” 
statements. These written requirements represent the attributes and capabilities that the C2 
system must possess to be useful and meet the needs of the stakeholders. These requirements are 
then translated into functions captured in the functional architecture using DoDAF. Needs 
Analysis was then re-evaluated to determine if further stakeholder input was needed for 
clarification, if the mission threads were adequately defined, and if the threats were fully 
established. 

The Modeling and Analysis phase provided simulation and model verification of 
functional architecture identified during the Functional Analysis phase. Analysis was conducted 
to identify methods in which the common architecture could yield potential savings in the areas 
of training and capability upgrades. The previous phases were re-evaluated to determine if the 
requirements, architecture, mission threads, and threats were adequately developed. The 
stakeholders were also contacted to validate the progress of the project. 

This project resulted in a documented process for developing scalable enterprise 
requirements and architectures, as well as specific requirement and architecture sets to support 
the identified project mission threads. The following sections more clearly define the phases of 
the process. 
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1. Needs Analysis Phase 

a. Stakeholder Analysis 

The purpose of the stakeholder analysis task was to identify the stakeholders for the ship 
C2 system and to elicit guidance from the stakeholders and official documents to identify 
direction for other needs analysis tasks. As such, the stakeholder analysis did not produce any of 
the major end products of the project, namely the architecture and the C2 requirements, but it 
was still a vital step in the process. The stakeholder analysis provided foundational information 
for the follow-on tasks that ultimately led to the end-product development. 

The stakeholder analysis was conducted based on the infonnation in the problem 
statement. The stakeholder expectation of current and future threats was used in the threat 
assessment. The summary of naval doctrine was used to enhance the mission thread definitions. 
The stakeholders’ desires for system functionality helped define the architecture throughout 
development. The stakeholders’ values and metrics were incorporated into the value system 
design. Specific stakeholder needs were the basis for the requirements definition. The 
relationship between the Stakeholder Analysis task and the following tasks is depicted in Figure 
2 . 


Problem 

Statement 


Desired Functionality 


Stakeholder 

Stakeholder Needs 

Stakeholder Values & Metrics 

Analysis 



Current and 
Future Threats 


Threat 

Threat Parameters 

Assessment 



Doctrine 

Mission Thread 

Representative 
Mission Threads 

Definition 



Figure 2: Stakeholder Analysis Task Relationships 

The findings from the Stakeholder Analysis helped support the other tasks in Needs Analysis 
Phase, and also provided inputs into the other Phases of the SE process. 
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The stakeholder analysis began by identifying the key stakeholder organizations. Then 
the stakeholders were interviewed and a range of stakeholder documents were surveyed. 
Stakeholder interviews were conducted using a common set of questions. The survey of 
stakeholder documents ranged from high-level maritime policy to Naval Warfare Publications 
(NWP) and Naval Tactics, Techniques and Procedures (NTTP). These documents are listed in 
the stakeholder analysis section. 

b. Threat Assessment 

The objective of the threat assessment was to survey current and future threats to U.S. 
Navy platfonns with the purpose of influencing the requirements definition task. The inputs to 
the threat assessment were the problem statement and the stakeholder feedback on current and 
future threats. The primary intent of the threat assessment was to feed the threat parameters into 
the requirements definition task. The threat assessment was used to summarize the current and 
future threats and their related kinematic characteristics. The threat assessment was constrained 
to an unclassified level. Open sources, public sites, and publicly released U.S. government and 
United Nations documents are the main resources for threat specifications. Figure 3 summarizes 
the relationship of the Threat Definition task to other tasks. As a result from this analysis, threat 
parameters were established. 


Problem 

Statement Stakeholder 
Analysis 


Desired Functionality 
Stakeholder Needs 
Stakeholder Values & Metrics 


Current and 

Future Threats Threat Threat Parameters 
Assessment 


Doctrine 

Mission Thread 

Representative 
Mission Threads 

Definition 



Figure 3: Threat Assessment Task Relationships 

The Threat Assessment evaluated threats that were identified during the Stakeholder Analysis. 
Threat Parameters identified during this process were used to support requirements development. 
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c. Mission Thread Definition 


The development of mission threads provided a means of scoping and bounding the 
problem to a manageable level that would help identify the capabilities and limitations of the C2 
Architecture. The threads describe representative scenarios in which the C2 system is expected 
to perfonn, and provided a framework for the functionality of the C2 system. Inputs to the 
mission threads came from the outputs of the stakeholders’ analysis (such as summaries of Navy 
doctrine and publications) and were used to develop and refine the mission threads. The refined 
mission threads were then used to develop C2 system requirements (the requirements were 
derived from the mission threads to meet stakeholder needs). Figure 4 summarizes the 
relationship of the Mission Thread Definition tasks to the other tasks. As a result of this 
analysis, representative mission threads were developed. 


Problem 

Statement 


Stakeholder 

Analysis 


Desired Functionality 
Stakeholder Needs 
Stakeholder Values & Metrics 


Current and 
Future Threats 


Threat 

Threat Parameters 

Assessment 



Doctrine 


Mission Thread 
Definition 


Representative 
Mission Threads 


Figure 4: Mission Thread Definition Task Relationships 

Doctrine identified during Stakeholder Analysis helped define context, functionality and 
relationships to create mission threads. The mission threads formed part of the basis for 
requirements development. 
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2. Functional Analysis Phase 
a. Requirements Definition 

The purpose of the Requirements Definition stage of the project was to identify the 
functional requirements necessary to accomplish the SUW and MIO missions. The Stakeholder 
surveys conducted in the Needs Analysis phase, along with the mission threads, provided the 
initial direction for this stage. Once the broad mission functions were derived from the surveys 
and mission thread sequence diagrams, research of Navy and DoD doctrine and policy 
publications provided an additional level of detail for the requirements. This filled in some areas 
that had been unaddressed and expanded on those that were already addressed. The functional 
requirements subsequently populated a CORE model, described below, which was used to 
validate the adequacy of the function list. CORE is a commercially available systems 
engineering and design software tool. The requirements list was further expanded in the Value 
System Design stage by adding perfonnance and constraint requirements that quantify the 
capability of a specific instantiation of the architecture. Figure 5 summarizes the relationship of 
the Requirements Definition task to the other tasks. 


Threat Parameters 
Desired Functionality 
Representative Mission Threads 



A 

_^ 

Requirements 

Definition 


C2 Requirements 


'\ 


_> 



( - 





V x 

Value System 


L_s. 

Enterprise 

Architecture 

A 


Design 

\a 


Stakeholder Values and Metrics 
Representative Mission Threads 


IYi etr j cs Enterprise Architecture 

Threshold Values 


Figure 5: Requirements Definition Task Relationships 

Information from the Needs Analysis phase and the Value System Design were used to develop 
the C2 requirements. The C2 requirements then become the foundation for the Architecture and 
also supported the Modeling and Analysis phase. 
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b. Value System Design 


The objective of the Value System Design was to bridge together the stakeholder 
functional needs and the C2 requirements by using the mission threads and Navy Doctrine to 
formulate system objectives and develop threshold values. The Value System Design was also 
used to develop objectives and map those objectives to the stakeholder requirements through the 
use of associated values in the form of performance measures. Each requirement was then 
mapped to the function that it supported in order to provide full traceability between 
requirements and architecture functionality. Figure 6 summarizes the relationship of the Value 
System Design Task to the other tasks. 
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Figure 6: Value System Design Task Relationships 

information from the Needs Analysis phase and the Value System Design were used to develop 
the C2 requirements. The C2 requirements then become the foundation for the Architecture and 
also supported the Modeling and Analysis phase. 

c. Enterprise Architecture 

The Enterprise Architecture task defined the functionality of the C2 system and the C2 
system’s interfaces with other systems. The architecture was developed based on the C2 system 
requirements produced during the Requirements Definition task. As the architecture was 
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developed, the requirements were allocated to the C2 system functions. This ensured that the 
architecture addressed all of the C2 system requirements. Figure 7 summarizes the relationship 
of the Enterprise Architecture task to the other tasks. 


Threat Parameters 
Desired Functionality 
Representative Mission Threads 



Representative Mission Threads Threshold Values 

Figure 7: Enterprise Architecture Task Relationships 

C2 Requirements described the capability of the system. The Enterprise Architecture task 
developed the architecture products. 

3. Modeling and Analysis 

a. Modeling and Simulation 

The overall objective of the Modeling and Simulation (M&S) activities, seen in Figure 8, 
was to verify the architecture through the use of model-based systems engineering, an integral 
part of the requirements and architecture development process. M&S was used to verify and 
improve the operational and the functional activity models that were derived from the 
architecture and based on the requirements. 

Verification was accomplished using two different, but complementary, M&S 
techniques: discrete event simulation and Colored Petri Nets (CPN). The purpose of this 
verification effort was to verify that the architecture was complete, internally consistent and 
executable. The discrete event simulation was also used to create a dynamic view of the OV-5 
and SV-4. 
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Figure 8: Modeling and Simulation Task Rel 

lationships 


C2 Requirements described the capability of the system. The Enterprise Architecture task 
developed the architecture products. 

b. Cost Analysis 

The Cost Analysis task was conducted in parallel with M&S and was the culminating 
activity for the entire project. Activities in the prior phases were conducted to provide input (in 
the form of the architecture products) into the Cost Analysis task. The Cost Analysis task 
investigated multiple means of establishing a quantitative measure of cost comparison, ultimately 
using school house training hours as the metric. The architecture functionality was compared 
with available training information from two combat system training courses to investigate if a 
common architecture could result in lifecycle cost savings (measured in tenns of training hours). 
Figure 9 summarizes the relationship of the Cost Analysis task to the other tasks. 
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Figure 9: Cost Analysis Task Relationships 

Training Information and the Enterprise Architecture are used to estimate potential savings 
(measured in training hours) that could be achieved by using a common set of C2 requirements. 


D. ASSUMPTIONS 

When using the term command and control, the project makes no distinction between the 
human, hardware, software, and procedural elements of the system. The project identifies the 
functionality of command and control as it applies to the two mission threads. The project does 
not further decompose the functions to a physical architecture where distinctions between 
human, hardware and software actions would become more evident. In other words, the scope of 
the project ends at defining C2 functionality, and does not identify the components and 
procedures necessary to achieve the functionality. This activity is left to the trade space for 
follow-on efforts. 

The project acknowledges that the requirements and architecture do not represent a 
complete set of C2 functionality. Project resource constraints were prohibitive in producing a 
comprehensive C2 architecture and requirements set. However, the project does demonstrate a 
process for developing common requirements and architecture, and then using the architecture to 
identify potential areas of cost savings. It is the expectation of the project team that this process 
will provide valuable insight, and will be scalable, for developmental efforts for actual systems. 
It is also expected that the requirements and architecture products produced by this project will 
provide a baseline for future development efforts. 
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II. NEEDS ANALYSIS 


The System Engineering Process began with the Needs Analysis phase. The given 
problem statement was refined to further understand the needs and expectations of the 
stakeholders. In this phase the mission threads were researched and more clearly defined as part 
of the project proposal. The threats against which the C2 architecture and requirements must 
perform were also identified. These tasks occurred in parallel. 

A. STAKEHOLDER ANALYSIS 

1. Background 

The objectives of the stakeholder analysis were to identify the key organizations that can 
affect or will be affected by the development of the ship C2 system and also to identify 
stakeholder objectives and requirements. Stakeholders included interested parties such as future 
users, system developers, and resource sponsors. 

The output of the stakeholder analysis was a summary of the key stakeholder needs and 
objectives identified from stakeholders and their documents. The stakeholder needs and 
objectives served to frame the requirements definition, enterprise architecture and value system 
design tasks during the functional analysis phase and ensured that the resulting products would 
satisfy the stakeholders. 

2. Stakeholders 

A full range of stakeholders were identified by considering the operational fleet 
organizations and the decision authorities of the three components of the DoD system life-cycle 
processes: the Joint Capabilities Integration and Development System (JCIDS), the Defense 
Acquisition System (DAS) and the Planning, Programming, Budgeting, and Execution System 
(PPBES). Figure 10 depicts the stakeholder organizations identified and their organizational 
relationships. Further details on specific organizations that were identified are provided in Table 
1 . 
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Figure 10: Stakeholder Organizational Relationships 

These are the organizations identified by the project as stakeholders. Figure 10 indicates the 
organizational relationship between these organizations. The dashed line represents the 
coordination and support role that Fleet Forces Command provides to sustain the fleet. 
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Table 1: Stakeholder Organizations and Roles 

This table identifies the organizations and describes the roles of the stakeholder organizations 
identified for this project. [From Department of the Navy, Research, Development and 
Acquisition, “ASN RDA”, 2009; Navy.mil, “The Operating Forces”, 2009; Navy.mil, “The 
Secretary of the Navy”, 2009; Navy.mil, “The Shore Establishment”, 2009]. 


Organization 

Role 

Secretary of the Navy (SECNAV) 

Responsible for all affairs of the U.S. 

Navy. 

Office of the Chief of Naval Operations 
(OPNAV) 

Executes the Joint Capabilities Integration 
and Development System and Planning, 
Programming, Budgeting, and Execution 
System, defining requirements and 
budgeting for U.S. Navy systems. 

N85 (Director, Expeditionary Warfare) 

N86 (Director, Surface Warfare) 

N88 (Director, Air Warfare) 

N6F (Director, Warfare Integration) 

Fleet Force Command 

Trains, equips and mans the fleet. 

Atlantic Fleet 

Pacific Fleet 

Assistant Secretary of the Navy for 
Research, Development & Acquisition 
(ASN (RD&A)) 

U.S. Navy decision authority in the 

Defense Acquisition System. 

Chief Systems Engineer (CHSENG) 

Provides overall Systems Engineering 
guidance to Navy acquisition. 

System Commands 

Provide engineering personnel under a 
matrix arrangement with the PEOs. 

Naval Sea Systems Command 
(NAVSEA) 

Naval Air Systems Command (NAVAIR) 

Space and Naval Warfare Systems 
Command (SPAWAR) 

Program Executive Offices 

Responsible for execution of the Defense 
Acquisition System. 

Ships 

Carriers 

Integrated Warfare Systems (IWS) 

Command, Control, Computers, 
Communication, and Intelligence (C4I) 

Unmanned Aviation and Strike Weapons 
(U&W) 

Littoral and Mine Warfare (LMW) 

Deputy Assistant Secretaries of the 

Navy (DASN) 

Oversee major U.S. Navy acquisition 
programs for ASN (RD&A). 

Ships/IWS 

Air 

C4I & Space 
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Several stakeholders were identified to support this project execution. These 
stakeholders have worked, or are currently working, in the C2 requirements and architecture 
areas. They have provided valuable input to the project throughout the process. These 
stakeholders are listed below in Table 2. 


Table 2: Project Stakeholders 

This is a list of the identified stakeholders who were able to participate in the project. These 
stakeholders acted as advisors and provided input and guidance to the project team. 


Name 

Organization 

Job Description 

Marc Stockbauer 

OPNAV N864 

Science and Technology Advisor for the Maritime 
Warfare/Surface Strike Branch (N864). 

Represents N864 interests in the approval and 
execution of ongoing and proposed Future Naval 
Capabilities (FNC), Joint Capability Technology 
Demonstrations (JCTD), Rapid Technology 
Transitions (RTT), Rapid Development and 
Deployment (RDD) and Defense Advanced 
Research Projects Agency (DARPA) efforts. 

Gil Goddin 

Naval Surface 
Warfare Center, 
Dahlgren 

Senior Systems Engineer in the Warfare Systems 
Department, Warfare Systems Engineering and 
Analysis Division and serves as Warfare Systems 
Definition Branch head. Serves as the enterprise 
Systems Engineer who works with Program 
Executive Office (PEO) Integrated Warfare 

Systems (IWS) to define commonality across 
platforms for combat system design. 

Tim Neel 

Naval Surface 
Warfare Center, 
Dahlgren 

Senior Combat Control Systems Engineer in the 
Warfare Systems Department, Combat Control 
Division. Develops advanced C2 architectures for 
Surface Navy Combat Systems. 

Doug Haas 

Naval Surface 
Warfare Center, 
Dahlgren 

Senior Technical Advisor to the Warfare Systems 
Department, Combat Control Division. Supports 
the department for combat control systems 
engineering matters regarding the continued 
advanced development of surface combatants. 
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3. Methodology 

The stakeholder analysis consisted of an evaluation of both Joint and Navy guidance and 
doctrine. Interviews with stakeholders helped to identify the objectives and development 
considerations that drove the architecture and requirements of the ship C2 system. In the 
evaluation of stakeholder documents, a full range of guidance was considered, from overarching 
maritime policy to surface warfare tactics, techniques, and procedures (TTP). The documents 
used in this analysis included U.S. Naval guidance, the Joint Functional Concepts (JFC) and 
Joint Integrating Concepts (JIC) from the Joint Chiefs of Staff and U.S. Naval doctrine, which 
are listed in Table 3. U.S. Naval guidance defines the missions the U.S. Navy performs and key 
characteristics of U.S. Navy perfonnance. The JFC define the functional capabilities of the joint 
force while the JIC define tasks, conditions, and standards [Chairman of the Joint Chiefs of Staff 
3010.01B, 2006], U.S. Naval doctrine defines how the U.S. Navy conducts its missions, 
specifically how C2 is executed within the Surface Warfare and Maritime Interception 
Operations missions. 


Table 3: Stakeholder Analysis Document List 

This is a list of the Joint and Navy publications that were researched for this project. Information 
gathered from these documents shaped the requirements and architecture development efforts. 


“A Cooperative Strategy for 21st Century Seapower” [United States Navy/United States 

Coast Guard, 2007] _ 

“Naval Operations Concept” [United States Navy/United States Marine Corps, 2006] _ 

“Joint Command and Control Functional Concept” [United States Department of Defense, 

20041 _ 

“Functional Concept for Battlespace Awareness” [United States Department of Defense, 

20031 _ 

“Command and Control Joint Integrating Concept” [United States Department of Defense, 

20051 _ 

“Universal Naval Task List” [Chief of Naval Operations, 2007] _ 

“Navy Surface Warfare Manual” [Office of the Chief of Naval Operations, 2007] _ 

“Naval Doctrine for Military Operations Other-Than-War” [Office of the Chief of Naval 

Operations, 1998] _ 

“Maritime Interception Operations” [United States Navy/United States Coast Guard, 2003] 


The information gathered from the documents above was used to begin the 
requirements listing and was used to develop interview questions for the participating project 
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stakeholders. A common set of questions were presented to each of the stakeholder (reference 
Appendix B). The comments received were integrated with the main points from the guidance 
and doctrinal publications and are described in the following sections. 

The results of this analysis were then divided into four sections: operational settings and 
threats; tasks and functionality; values and metrics; and acquisition guidance. Each section 
supported follow-on tasks in the Needs Analysis and the Requirements Analysis phases of the 
project. The stakeholder analysis also identified several items of information within the SUW 
and MIO TTPs that supported the mission thread and architecture development. These items 
included mission types, command organization and system interface requirements. To avoid 
duplication, these items were directly incorporated into the mission thread and architecture 
sections. 

4. General Results 

a. Operational Settings and Threats 

National-level defense guidance defines the missions the U.S. Navy is expected to 
perform in the future as well as the key characteristics of U.S. Navy perfonnance. “A 
Cooperative Strategy for 21st Century Seapower” defines the following missions for naval 
forces: forward presence, deterrence, sea control, power projection, and maritime security 
[United States Marine Corps/United States Navy/United States Coast Guard, 2007]. However, 
the Naval Operating Concept (NOC) cites that the geographic focus of these missions are 
changing to emerging areas such as Africa, South America and Indonesia, specifically the Strait 
of Malacca [United States Navy/United States Marine Corps, 2006]. The changing geographic 
focus is important since the worst-case environmental conditions the U.S. Navy may face, such 
as sea state, atmospheric conditions, clutter levels, will drive the requirements on the C2 system 
[Goddin, 2008]. 

Threats were divided into traditional and irregular threats. Traditional threats to naval 
platforms include a wide variety of weapons from surface combatants, submarines, aircraft and 
coastal defenses. Traditional weapons that may be employed against naval platforms include 
Anti-Ship Cruise Missiles (ASCM), air-to-surface missiles and bombs, mines, torpedoes, naval 
guns, and rocket projectiles [Office of the Chief of Naval Operations, 2007]. 
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Irregular threats span from smaller craft and Unmanned Aerial Vehicles (UAVs) to 
catastrophic threats. Fast attack craft use crew-served weapons, rockets, ASCM, wake-homing 
torpedoes and water-borne Improvised Explosive Devices (IED) as a threat in littoral waters 
[Office of the Chief of Naval Operations, 2007]. The small boat threat is of specific concern, 
including craft as small as personal watercraft. This threat is further complicated in a high- 
clutter, high sea state operational environment [Goddin, 2008], Aircraft, such as small planes 
and UAVs, submersibles, and commercial platforms pose potential harm. Criminal 
organizations and piracy have evolved with organized attacks and improved communications 
systems and weapons. Disruptive information technology, directed energy, and cyber terror also 
pose as threats to naval platforms. Catastrophic threats, namely Weapons of Mass Destruction 
(WMD) remain a threat as well [Office of the Chief of Naval Operations, 2007]. 

b. Tasks and Functionality 

The “Universal Naval Task List” (UNTL), Version 3.0 defines the tasks that the U.S. 
Navy performs. In particular, Chapter 3 defines the tactical-level tasks in the Navy Tactical Task 
List (NTTL). The NTTL was a useful tool to assess the range of tasks that the ship C2 system 
should be able to support. Four major Navy Tactical Tasks (NTA) were identified to scope the 
ship C2 system architecture: 

• Conduct Counter-mobility (NTA 1.4), 

• Perform Collection Operations and Management (NTA 2.2), 

• Process Targets (NTA 3.1), and 

• Acquire, Process, Communicate Information and Maintain Status (NTA 5.1) 
[Chief of Naval Operations, Commandant of the Marine Corps, 2007]. 

The tactical tasks are further decomposed in Table 4. 
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Table 4: Navy Tactical Tasks 

These are the NTAs that were used as the outline to develop the requirements and architecture. 


NTA 

Description 

1.4 

Conduct Counter-mobility: “To construct obstacles and employ area denial 
efforts including mines to delay, disrupt, and destroy the enemy. The 
primary purpose of counter-mobility operations is to slow or divert the 
enemy, to increase time for target acquisition, and to increase weapons 
effectiveness.” [UNTL v 3.0: 3-B-16 - 3-B-20] 

1.4.6 

Conduct Maritime Interception 

1.4.6.1 

Conduct Visit 

1.4.6.2 

Conduct Search 

1.4.6.3 

Conduct Seizure 

2.2 

Perform Collection Operations and Management: “To gather data, 
infonnation, and previously produced intelligence from all sources to satisfy 
the identified requirements.” [UNTL v 3.0: 3-B-33 - 3-B-35] 

2.2.1 

Collect Target Infonnation 

2.2.1.1 

Detect Contacts 

2.2.1.2 

Track Contacts 

2.2.1.3 

Classify Contacts 

2.2.1.4 

Identify Contacts 

2.2.1.5 

Localize Contacts 

3.1 

Process Targets: “To positively identify and select land, sea, and air targets 
that decisively impact battles and engagements and match targets with 
appropriate firepower systems ...” [UNTL v 3.0: 3-B-44 - 3-B-45] 

3.1.1 

Request Attack 

3.1.2 

Select Target to Attack 

3.1.3 

Select Platform(s) and System(s) for Attack 

3.1.4 

Develop Order to Fire 

3.1.5 

Conduct Tactical Combat Assessment 

5.1 

Acquire, Process, Communicate Information and Maintain Status: “To 

obtain information on the mission, enemy forces, neutral/non-combatants, 
friendly forces, terrain, and weather. To translate that infonnation into 
usable form and to retain and disseminate it.” [UNTL v 3.0: 3-B-91 - 3-B- 
941 

5.1.3 

Maintain Information and Naval Force Status 

5.1.3.1 

Maintain and Display Tactical Picture 

5.1.3.2 

Maintain and Display Force Command and Coordination Status 

5.1.3.3 

Maintain and Display Units Readiness 


The listing of Navy tactical tasks is limited to the detection, tracking, classification, 
identification, and reporting and boarding of surface threats as well as the detection, tracking, 
identification, and reporting of merchant ships during MIO. NTA (Navy Tactical level of war 
tasks) 1.4.6 addresses the conduct of Visit, Board, Search and Seizure (VBSS). NTA 2.2.1 


20 




covers the detection, tracking, classification and identification of contacts. NTA 3.1.1 includes 
C2 tasks associated with threat evaluation and weapons assignment. NTA 5.1.3 focuses on 
threat and status reporting. 

The “Navy Surface Warfare Manual” defines a comparative set of top-level functions, 
tenned the Surface Warfare kill chain, which was directly applicable to the project requirements 
and architecture development efforts. The components of that kill chain are: find, fix, track, 
target, engage, and assess [Office of the Chief of Naval Operations, 2007]. 1 

• Find: Monitor environment 

• Fix: Localize the potential target 

• Track: Maintain continuous track 

• Target: Check for Rules of Engagement (ROE) and coordination measures and match 
weapon and sensor to target 

• Engage: Issue the engagement order and create effects on target 

• Assess: Assess where desired effects were achieved, including physical and functional 
damage 

Within the find, fix, and track phases, off-board platforms such as helicopters, UAVs and 
Unmanned Surface Vehicles (USV) play an extensive role to extend detection ranges. The 
integration of those sensors into the tactical picture may be considered a key factor [Haas and 
Neel, 2008]. Also, Chemical, Biological and Nuclear (CBN) sensors, either shipboard or on 
UAV or USV, play a role in identifying standoff ranges for threats [Stockbauer, 2008], 

Within the target phase of the kill chain, the principles of preplanned responses have 
significant impacts for the ship C2 system. “Preplanned responses will be executed for all 
critical and unknown surface contacts that may enter into the SUW AO as established by the 
strike group commander” [Office of the Chief of Naval Operations, 2007]. This implies that 
there is a requirement for the ship C2 system to be able to provide automated decision support 
based on preplanned responses to any and all surface contacts. 


'The project uses the kill chain terminology as defined by the Navy in “Navy Warfare Publication: Navy Surface 

Warfare Manual NWP 3-20”, which is consistent with the joint document NTTP 3-60.1 

"MULTI-SERVICE TACTICS, TECHNIQUES, AND PROCEDURES FOR TARGETING 

TIME-SENSITIVE TARGETS", dated April 2004. Other documents exist (e.g. the Capabilities Based Assessment 

Users Guide, December 2006, JCS J-8) which use slightly different terminology for the kill chain. 
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Part of preplanned responses, is support for automated identification. For surface 
contacts, this includes detection of a muzzle flash by an Electro-Optical/Infra-Red (EO/IR) 
sensor, range rings, Identification Friend or Foe (IFF) returns, or kinetic information. The next 
step is support for an auto-engage capability that can be configured and initiated by the operator 
[Haas and Neel, 2008], 

The engage phase of the kill chain is not limited to kinetic effects. Non-kinetic effects 
are expected to have a growing influence in future SUW and MIO missions, especially against 
small boats. Potential non-kinetic effects included Radio Frequency (RF) weapons to disable 
engines and prop-fouling devices [Haas and Neel, 2008]. Non-damaging effects are a specific 
subset of non-kinetic effects for use in commercial and civilian maritime craft interdiction 
[Stockbauer, 2008]. 

Success in a SUW mission depends upon the ability to make better decisions faster than 
the enemy can react to them, known as decision superiority [Office of the Chief of Naval 
Operations, 2007]. Decision superiority consists of two elements, information superiority and 
knowledge superiority. Information superiority is defined as “the operational advantage derived 
from the ability to collect, process, disseminate, and display an uninterrupted flow of tactically 
and strategically relevant information while exploiting or denying an adversary’s ability to do the 
same” [Office of the Chief of Naval Operations, 2007, 1-8]. The Department of Defense 
Dictionary of Military and Associated Terms includes a similar definition of information 
superiority [Joint Staff, 2008]. Knowledge superiority is the advantage over the enemy in 
education, training, and experience [Office of the Chief of Naval Operations, 2007]. 

The ability to accurately identify friend, neutral, and hostile ships in a saturated 
environment is a major factor in decision superiority [Haas and Neel, 2008; Stockbauer, 2008; 
Goddin, 2008], This involves the integration of all available sensor sources and Indications & 
Warnings (I&W) that support accurate determinations of identity that can be acted upon with 
high degrees of confidence. This includes the integration of EO/IR and acoustic data into the 
tactical picture. This high volume of data leads to the need for tailor-able tactical and 
operational pictures where the data displayed is driven by the mission requirements [Haas and 
Neel, 2008], 

Other major concepts include Distributed Weapons Control, and Engage on Remote. 
Both concepts depend on real-time sensor netting. Real-time sensor netting is the sharing of 
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sensor data to ensure a common picture across platforms. Distributed Weapons Control includes 
the distributed coordination of engagements while Engage on Remote is the ability to engage 
targets using sensor data from another platform. The keys to Distributed Weapons Control, 
Engage on Remote and real-time sensor netting are time accuracy, navigation accuracy, and data 
registration [Haas and Neel, 2008]. 

Several key needs specific to the MIO mission were also identified during Stakeholder 
Analysis. Maintenance of the surface picture was an overarching element of MIO. Maintenance 
of the surface picture includes: accounting for all surface contacts by name, track number and 
MIO control contact number, maintaining query and boarding status of each surface contact, 
updating and maintaining the tactical data link, and promulgate surface situation reports 
(SITREPs) [United States Navy/United States Coast Guard, 2003]. 

The C2 system needs to be able to integrate intelligence data into the MIO tactical 
picture. The Maritime Intercept Commander (MIC) Intelligence Officer needs to have the ability 
to draw from data from several organizations and data sources that can be used to support the 
classification and identification of commercial vessels, including: Office of Naval Intelligence 
(ONI) Maritime Target Development Division National Maritime Intelligence Center, Office of 
Naval Intelligence Merchant Ship Characteristics Hidden Compartment Book, and Sealink 
Databases of Vessels Electronic Intelligence parameters correlated to known sanctions violators 
[United States Navy/United States Coast Guard, 2003], 

The Automatic Identification System (AIS) resides on commercial and naval ships and 
broadcasts ship information in the Very High Frequency (VHF) maritime band. The AIS 
transponder broadcasts ship name, classification, call sign, registration number, course and 
speed, and the International Telecommunications Union Maritime Mobile Service Identity 
(MMSI) to other AlS-equipped ships [United States Coast Guard, 2008]. This ability enables 
AlS-equipped ships conducting MIO operations to correlate ship names with intelligence 
databases prior to first interrogation. Of course, AIS is a cooperative system, meaning that a 
vessel that does not want to be easily identified can disable its AIS broadcast system. 
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c. Values and Metrics 


A wide array of metrics applies to the ship C2 system. Common metrics include 
Operational Availability (A 0 ) [Goddin, 2008] and required bandwidth [Stockbauer, 2008]. 
Operational availability is a measure of the degree to which one can expect a system to work 
properly when required. [Defense Acquisition University, 2005]. 

Other programs completed extensive work in the development of C2 related metrics. The 
Single Integrated Air Picture (SIAP) developed a suite of metrics relating to the common tactical 
and operating pictures that can be adapted to the surface picture [Stockbauer, 2008]. Key 
metrics from the SIAP Attributes [Single Integrated Air Picture System Engineering Task Force, 
2003] that will serve as a basis for key C2 system performance requirements include: 

• Clarity: (Ambiguous Tracks) The percentage of real world objects that have more than 
one track assigned. (Spurious Tracks) The percentage of tracks without a corresponding 
real world objects. 

• Continuity: The number of track numbers assigned to each real world object. 

• Identification Completeness: The percentage of tracked objects that are in an identified 
state. 

• Identification Correctness: The percentage of tracked objects that have the correct 
identification. 

d. Acquisition Guidance 

PEO IWS has developed a vision for the engineering of future surface navy combat 
systems. Much of the vision provided is directly applicable to the development of the C2 system 
architecture and requirements. The PEO IWS vision is based on three major principles: a 
componentized system architecture using open information standards; a system product line 
developed based on a common, objective architecture; and a decoupling of system development 
from platform development while still accommodating platform-specific needs [Benedict, 2008]. 
In line with this strategy, the stakeholders provided specific acquisition guidance that ensures the 
C2 system design will support the future engineering vision for surface navy combat systems. 

For existing platforms, the C2 system should have no impact to Cruiser-Destroyer 
manning requirements and no adverse impact to physical C2 spaces [Stockbauer, 2008]. For 
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existing and new platforms, the C2 system must apply Modular Open Systems Architecture 
(MOSA) design principles [Under Secretary of Defense for Acquisition, Technology and 
Logistics, 2003; Stockbauer, 2008] and maintain independence of the C2 system application 
from the underlying Commercial-Off-The-Shelf (COTS) computing plant [Stockbauer, 2008]. A 
MOSA design is defined by key principles: use of a modular design, definition of key interfaces 
and use of open standards. A modular design involves the development of components that 
implement cohesive functionality, hide the inner workings of the component, limit impacts to 
other components and enable component reuse [Defense Acquisition University, 2009]. 

All of the standards employed by the ship C2 system must be consistent with the DoD 
Information Technology Standards Repository (DISR) as dictated by CJCS Instruction 6212.01, 
Interoperability and Supportability of Information Technology and National Security Systems 
[Stockbauer, 2008; Defense Acquisition University, 2009]. 

All life-cycle considerations need to be examined for the ship C2 system architecture. 
Specifically training, including training timelines, schoolhouse requirements, and cost must be 
considered during development [Stockbauer, 2008], 

5. Stakeholders Analysis Conclusions 

The stakeholder analysis was conducted by surveying publications that ranged from U.S. 
Naval guidance to tactics, techniques and procedures and by interviewing the project 
stakeholders. Through analysis several key stakeholder needs and objectives were identified. 
These results were divided into operational settings and threats, tasks and functionality, values 
and metrics, and acquisition guidance. These needs and objectives were summarized and used to 
support subsequent tasks. 

The stakeholder analysis identified a categorization of threats that served as the basis 
for the threat assessment. The threat categories included traditional threats to naval platforms: 
surface combatants, submarines, aircraft and coastal defenses. Threat weapons included ASCM, 
air-to-surface missiles and bombs, mines, torpedoes, naval guns, and rocket projectiles [Office of 
the Chief of Naval Operations, 2007]. The threat categories also included irregular threats such 
as: fast attack craft (FAC) and small boats, small planes and UAVs, submersibles, commercial 
platforms, criminal and piracy organizations, disruptive information technology, directed energy, 
cyber terror and WMD [Office of the Chief of Naval Operations, 2007; Goddin, 2008]. 
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The stakeholder analysis also identified several key functional needs from the 
stakeholders. These needs are summarized in Table 5. 


Table 5: Stakeholder Functional Needs 

Table 5 summarizes the key function needs identified during the Stakeholder Analysis phase of 
the project. 


_ Stakeholder Functional Needs _ 

Support the entire SUW kill chain (find, fix, track, target, engage and assess) [Office 

of the Chief of Naval Operations, 2007] _ 

Positively identify contacts using all available sensors [Goddin, 2008; Haas and Neel, 

20081 ___ 

Integrate off-board sensors into the tactical picture [Haas and Neel, 2008] _ 

Support automated identification (e.g. detection of muzzle flashes with an EO/IR 

sensor, range rings, IFF returns or kinetic information) [Haas and Neel, 2008] _ 

Support distributed weapons control and real-time sensor netting [Haas and Neel, 

20081 _ 

Support pre-planned responses (PPR) [Office of the Chief of Naval Operations, 2007] 

Employ non-kinetic and non-damaging effects [Stockbauer, 2008] _ 

Maintain the MIO picture, including query and boarding status, track reporting and 

SITREPs [United States Navy/United States Coast Guard, 2003] _ 

Integrate intelligence data into the MIO tactical picture [United States Navy/United 

States Coast Guard, 2003] _ 

Integrate AIS data into MIO contact classification and identification [United States 
Coast Guard, 2008] _ 


The overarching stakeholder objective was decision superiority. This translated into 
metrics needed to assess the accuracy and speed with which the C2 system would distinguish 
between neutral and hostile contacts in a saturated environment, including track picture clarity, 
continuity, identification completeness and identification correctness [Haas and Neel, 2008; 
Goddin, 2008; Single Integrated Air Picture System Engineering Task Force, 2003], Required 
values will be addressed in Section III.A of this report. 

The stakeholder analysis was also used to elicit specific guidance on the acquisition of 
the ship C2 system. This guidance was used to drive the development of the C2 system 
architecture. Specific guidance on the C2 system architecture included: no impact to manning; 
must use a MOSA design; and must minimize life-cycle impacts. 
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B. MISSION THREADS ANALYSIS 


1. Background 

A mission thread is a descriptive process that entails what actions the systems must 
perform in a specified area of operation and includes the people, hardware, and software that are 
involved in perfonning these missions. Mission threads are generally derived from existing 
doctrine, such as the Naval Task List and stakeholder needs and wants that suggest several 
missions that a task force or battle group system should perfonn. The mission thread analysis 
utilized the doctrine identified in the Stakeholder Analysis as input to the mission thread 
definition. 

Mission threads were needed for several reasons: identifying system functionality, 
identifying a reasonable operational environment in which the system would be expected to 
perform, and defining system boundaries. In addition, mission thread analysis facilitated in 
generating C2 requirements for the project. It should be noted that for both SUW and MIO 
mission threads, C2 includes functionality that would be assigned to shipboard personnel, 
hardware and software required to perfonn the mission. The outputs of the mission threads 
analysis included boundaries, high level interface definition, and functionality required to meet 
the stakeholder needs identified in the Needs Analysis phase of the project. 

2. Methodology 

A mission threads analysis was perfonned to further define the threads identified in the 
project proposal. The threads aided in the development of the C2 architecture and requirements. 
A representative operational scenario was identified to demonstrate the functionality that a C2 
Architecture would be expected to perform to support the mission. The inputs from the 
stakeholder analysis, navy doctrine, and publications were then organized into a scenario and 
event sequence that was consistent with existing doctrine. The threads include a text description 
of the scenario and an activity diagram depicting the operational nodes and the functionality 
conducted to complete the mission. The operational nodes are represented as column headers, 
and the activities perfonned by each node are represented by the graphics in each column. Both 
threads, SUW and MIO, have an operational node labeled “Command and Control” which 
represents the functionality of the project C2 system. All activities in the “Command and 
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Control” column (swim lane) are considered part of the C2 system. All other activities are 
necessary to complete the mission, but are considered outside the boundary of the C2 System 
functionality. 

The mission threads analysis confines the multiple and diverse missions roles that a C2 
architecture should be capable of and focuses the analysis and boundaries of the project on two 
particular mission threads that are diverse enough, yet stress C2 system interfaces to simulate 
operating in a real world environment. Furthennore, the threads were used in the development 
of the OV-ls and C2 requirements. Upon further input from the threat assessment, the mission 
threads were refined to support the requirements and architecture defined in later sections. 

3. Surface Warfare 

a. Overview 

The Surface Warfare (SUW) mission thread depicts a surface warfare activity, focused 
particularly on the C2 system aboard a Navy combatant platform while executing the SUW kill 
chain process [Office of the Chief of Naval Operations, 2007] in open ocean operations. The 
thread is divided into three “swim lanes”: Sensor Systems, C2, and Engagement Systems. This 
thread focused on the C2 functions, processes, and interfaces required in supporting the mission. 

b. Scenario Baseline Description 

A surface action group (SAG) [Office of the Chief of Naval Operations, 2007] consists of 
two guided missile destroyers (DDG) and one guided missile frigate (FFG) defending the 
maritime maneuver area in the Indian Ocean. All ships have Condition III watch stations 
manned. Condition III is defined as a wartime steaming with at least half of the systems at a 
ready status at all times [Cutler, 2008]. Each destroyer has one embarked helicopter to support 
over-the-horizon (OTH) search and targeting capabilities. The purpose of the maritime 
maneuver area defense operations, as has been seen in traditional roles, is to protect the friendly 
sea line of communication (SLOC) by preventing enemy combatants from operating in the area 
[Office of the Chief of Naval Operations, 2007]. Figure 11 is an operational view (OV-1) 
depicting the interfaces between the various naval platforms involved in the scenario. The 
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activity diagram (Figure 12) focuses in on the specific C2 activities that are perfonned by the C2 
system aboard a single ship. 
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Figure 11: Operational View: Surface Warfare 

This Operational View provides a high level depiction of the operational environment in which the 
SUW scenario is conducted. 

The engagement systems and C2 functionality depicted in Figure 12 are organic to one 
DDG. The Sensor System swim lane represents organic and non-organic sensors. The 
remaining DDG and FFG in the SAG serve as non-organic sensor platforms for the purposes of 
this thread. A hostile combatant is operating in the area. The scenario is divided into five kill 
chain phases. 


29 










Figure 12: SUW Kill Chain Mission Thread 

The SUW activity diagram applies the kill chain to an SUW scenario. The focus of this diagram is 
the Command and Control swim lane, which is used to identify and bound C2 functionality. 
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Within the ‘Find/Fix’ phase the C2 system defines the search plan and promulgates it to 
the Sensor Systems. The search will either be directed or area [Office of the Chief of Naval 
Operations, 2007], The sensors conduct the search and find a surface contact. 

The Sensor Systems then localizes the track and provides track information to C2system 
in the ‘Fix/Track’ phase. Using all available information, the C2 classifies the track as a 
combatant and reports tracking information to other surface platforms and up the chain of 
command, and identifies it as hostile [Office of the Chief of Naval Operations, 2007]. C2 
applies Rules of Engagement and decides to engage the track. 

In the ‘Target’ phase the C2 system considers sensor and weapon system information to 
conduct targeting. Targeting includes consideration of factors such as: desired effects, available 
options, deconfliction, weapons target pairing, threat defense capabilities and environmental 
factors [Office of the Chief of Naval Operations, 2007]. 

The C2 system then sends an engagement order to the Engagement Systems to conduct 
the engagement during the ‘Engage’ phase. C2 monitors the status of the engagement via inputs 
from the Sensor and Engagement Systems. 

Finally in the ‘Assess’ phase C2 receives battle damage indicators from the Sensor and 
Engagement Systems and perfonns a battle damage assessment. Based upon the battle damage 
assessment, C2 will decide if the target needs to be reengaged. If the target does not need to be 
reengaged, the kill chain is complete and all systems assess readiness status. 

c. Scenario Exceptions 

There are three exceptions associated with this thread. Exceptions are “alternative 
endings” to the baseline scenario. The baseline scenario describes one course of decisions and 
actions. Exceptions explore alternative actions and decisions that may occur throughout the 
scenario. Exceptions cannot address every possible alternative scenario, but they do try to 
capture common alternatives to the baseline. 

The first exception is the possibility that the target is not to be engaged. C2 decides not to 
engage the contact based upon parameters such as classification and identification or ROE. The 
kill chain is interrupted, and the action is complete. All systems assess readiness status. Surface 
search is resumed based upon C2 direction [Office of the Chief of Naval Operations, 2007]. 
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The second exception is the possibility for reengagement of the target due to a positive track. 
Battle damage assessment indicates that the target had not been eliminated [Office of the Chief 
of Naval Operations, 2007]. C2 decides to reengage. C2 still has a positive target classification 
and identification. C2 applies ROE and engages the target again in accordance with the baseline 
description. 

The third exception is the possibility for reengagement of the target due to a lost track. Battle 
damage assessment indicates that the target had not been killed. C2 decides to reengage. The 
target track is lost. C2 identifies a search plan to regain the target track(s) and conducts the 
SUW kill chain in accordance with the baseline description [Office of the Chief of Naval 
Operations, 2007]. In order to limit the scope of the project due to time constraints single 
contacts were decided to be the focus of the SUW mission thread. 

4. Maritime Interception Operations 

a. Overview 

This thread particularly focuses on the use of C2 aboard a Navy combatant platform 
while performing Maritime Interception Operations in a peacetime environment. A high-level 
depiction of the operational environment (OV-1) is shown in Figure 13. The thread is divided 
into five swim lanes: Intelligence, Surveillance and Reconnaissance Systems; Maritime 
Intercept Commander; Organic C2: Organic Sensors; and Boarding Team. The thread focuses 
on the C2 functions, processes, and interfaces required to support the mission, see Figure 14. A 
distinct difference between the MIO mission thread and the SUW mission thread is the stronger 
reliance on Intelligence, Surveillance and Reconnaissance (ISR) assets and own ship sensor 
assets. In the SUW thread, a wider variety of sensor resources are available from accompanying 
ships. In the MIO thread, these external sensors are not available. 

b. Baseline Description 

Deployed as part of a Carrier Strike Group (CSG), a DDG is operating independently to 
conduct MIO in the Indian Ocean, as shown in Figure 13. The DDG has Condition III (wartime 
steaming with at least half of the systems at a ready status at all times) watch stations manned. 
The DDG has one embarked helicopter to support MIO and OTH search capabilities. The DDG 
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operates within the littorals and maneuvers up to, but not within, 12 nautical miles of land 
[United States Navy/United States Marine Corps/United States Coast Guard, 2007]. The sensor 
systems, C2 functionality, and boarding team depicted are organic to the DDG. The ISR 
represented organic and non-organic ISR assets. 



Figure 13: Operational View: Maritime Intercept Operation 

The MIO OV-1 provides a high level depiction of the MIO operational environment. 


c. MIO Chain of Events 

The following sequence of events describes the MIO scenario and the activities depicted 
in Figure 14. A vessel of interest is operating in the area. 
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Figure 14: MIO Mission Thread 

The MIO activity diagram depicts the events that occur during the MIO scenario. The focus of 
this diagram is the Command and Control swim lane, which is used to identify and bound C2 
functionality. 

ISR assets notify C2 that a merchant vessel of interest is operating in the area [United 
States Navy/United States Coast Guard, 2003], C2 defines the search plan and promulgates it to 
the sensor systems. The search is either a directed search pattern or area search pattern [Office 
of the Chief of Naval Operations, 2007]. 

The sensors conduct the search and find a surface contact. The sensors localize the track 
and provide track infonnation to C2. Using all available information, C2 classifies the track as 
the merchant vessel of interest and identifies it as assumed friendly [Office of the Chief of Naval 
Operations, 2007]. C2 applies ROE as promulgated by the Maritime Intercept Commander 
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(MIC), and queries the merchant vessel [United States Navy/United States Coast Guard, 2003]. 
The DDG Commanding Officer (represented within the Command and Control swim lane) 
assumes duties as the On Scene Commander (OSC) [United States Navy/United States Coast 
Guard, 2003], 

After the query is complete, C2 passes the query results to the MIC and to the ISR 
[United States Navy/United States Coast Guard, 2003]. The MIC evaluates the infonnation and 
authorizes C2 to board the merchant vessel. 

C2 directs the boarding party to board the merchant vessel [United States Navy/United 
States Coast Guard, 2003]. The boarding party provides status to C2 during the VBSS operation 
[United States Navy/United States Coast Guard, 2003]. C2 compiles the VBSS findings and 
forwards the infonnation to ISR and MIC. MIC evaluates the infonnation and directs C2 to 
divert the merchant vessel [United States Navy/United States Coast Guard, 2003]. The scenario 
is complete and all systems assess readiness status. 

d. Exceptions 

There are three exceptions associated with this thread. All three exceptions result in the 
tennination of the MIO action. The first of these exceptions is the case of a ‘do not query’ order. 
C2 decides not to query the merchant vessel, based upon parameters such as classification and 
identification or ROE. The MIO action is terminated. All systems assess readiness status. 
Surface search is resumed based upon C2 direction [Office of the Chief of Naval Operations, 
2007], 

The second exception is the event of a ‘Do not board’ order. MIC does not authorize 
boarding of the merchant vessel, based upon parameters such as results of the query or ISR 
information. The MIO action is terminated. All systems assess readiness status. Surface search 
is resumed based upon C2 direction [Office of the Chief of Naval Operations, 2007]. 

The third exception is the event of a ‘Do not divert’ order. MIC does not authorize boarding 
the merchant vessel, based upon parameters such as results of the VBSS or ISR information. 
The MIO action is tenninated. All systems assess readiness status. Surface search resumes based 
upon C2 direction [Office of the Chief of Naval Operations, 2007]. 
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5. Mission Thread Analysis Conclusions 

The mission thread analysis produced two viable representative mission threads from the 
analysis of doctrinal requirements represented in the stakeholder analysis. The mission threads 
were a result of analyzing how the project proposal and problem statement could be represented 
to meet doctrine needs identified in the stakeholder analysis. In addition, the mission threads 
analysis scoped and bounded the project proposal to a manageable level to help by focusing 
system functionality. The mission threads also depicted the operating environment-situation 
(OV-l’s) and the process flow to be used, as seen in Figure 14. Additionally, the mission threads 
facilitated the generation of the C2 requirements, which are addressed in the requirements 
definition section of this report. 

C. THREAT ANALYSIS 

1. Background 

The threat analysis explored current and future threats to U.S. Navy platforms and their 
capabilities as background for the requirements definition and mission thread definition tasks. 
These threats and their capabilities were identified during the Stakeholder Analysis. 
Characteristics of the threats were used to support key C2 requirements, such as the requirement 
to integrate off-board sensors into the track picture. Thus, while the threat assessment did not 
define specific requirements, it provided infonnation that was used to develop the C2 system 
requirements. 

The “Navy Surface Warfare Manual,” NWP 3-20, defines the categories of threats 
against U.S. naval platforms [Office of the Chief of Naval Operations, 2007]. Threats have 
evolved from conventional threats of surface combatants, submarines, and coastal defenses to a 
wide array of unconventional threats. These unconventional threats include FAC or patrol craft, 
small aircraft, UAVs, small submersibles, commercial platforms, piracy and crime, directed 
energy, cyber attacks, and WMDs [Office of the Chief of Naval Operations, 2007]. 

The threats against U.S. Navy ships have not remained constant. The geographic location 
of threats is changing from the blue water to littoral conflicts. Combined with the location, the 
threat has evolved from major naval adversaries to regional or coastal navies and non-state actors 
[United States Navy/United States Marine Corps, 2006]. 
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Threats from other conventional navies cannot be excluded from analysis. China 
possesses a large number of guided missile boats, frigates, destroyers and submarines as well as 
a single aircraft carrier [Global Security.org, “Chinese Warships,” 2008]. Other significant 
navies exist, particularly India and Russia. India has multiple aircraft carriers and a large 
number of frigates, destroyers, corvettes, patrol craft, and submarines [Global Security.org, 
“Indian Navy,” 2008]. While declining in size, the Russian Navy still possess submarines, 
destroyers, frigates, corvettes and patrol craft [Global Security.org, “Russian Warships,” 2008]. 
Emerging conventional threats include small torpedo and ASCM boats [Stockbauer, 2008]. To 
maintain a manageable scope, the focus of the conventional threat assessment was maintained on 
China’s Navy, whose platforms are representative of the types of threats from a conventional 
navy. 

The combination of insurgent and non-state actors using non-conventional weapons and 
conventional threats from other state navies poses a complex threat to U.S. Navy platforms. The 
conventional and unconventional threat sections detail some of the specific threat types that must 
be addressed in ship combat system requirements. 

2. Methodology 

The threat assessment was conducted by surveying available public intelligence sources. 
This assessment was constrained to an unclassified level, and only open source intelligence was 
used. Sources included congressional testimony, third party information sources such as 
GlobalSecurity.org, and public reports from the DoD and the United Nations. 

The threat categories were taken directly from NWP 3-20, the “Navy Surface Warfare 
Manual” (NSWM). The NSWM addresses all missions performed by U.S. Navy surface 
combatants, however, the mission threads were focused on the detection, tracking, classification, 
identification, reporting, and engagement or boarding of surface contacts. Thus, the threat 
assessment was limited to surface platforms, specifically, surface combatants, FAC, and 
commercial platforms, whose onboard systems and payloads could be used to threaten U.S. Navy 
ships. 
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3. Geographic Threat Regions 

Just as the threats have expanded, so has the geographic focus of U.S. Navy operations. 
The U.S. Navy has broadened from blue-water, major ocean conflict with established navies to 
littoral conflicts with non-state actors. The emerging regions include Africa, South America and 
the Straits of Malacca [United States Navy/United States Marine Corps, 2006]. Hotspots in 
recent years include: 

• Nigeria (Niger Delta): An unstable and impoverished region characterized by 
ethnic clashes, commercial sabotage, significant oil resources with little distribution 
of wealth, environmental damage, chronic poverty, and limited economic 
opportunities [Global Security.org, “Nigeria - Niger Delta,” 2008], 

• Colombia: A 38-year civil war involving two leftist insurgent groups and a right- 
wing paramilitary organization, focused in the eastern lowlands and southern 
rainforest. The leftist and right-wing groups have allied with drug trafficking 
organizations and conducted numerous kidnappings to fund the insurgency [Global 
Security.org, “Colombia - Insurgency,” 2008]. 

• Somalia: No national government exists and fighting between clans and factions is 
violent and flares up quickly, especially in the south. U.S. and United Nations 
peacekeeping missions led to significant casualties and were withdrawn in the mid- 
1990s [Global Security.org, “Somalia Civil War,” 2008]. Piracy is also common in 
the area and will be addressed in detail later in the document. 

• Indonesia (Aceh): An Islamic separatist movement has been fighting for an 
independent state since the 1970s. The Indonesian military has occupied the area 
since 1991, with substantial violence on both sides [Global Security.org, “Free Aceh 
(Aceh Merdeka),” 2008], 

4. Conventional Threats: Surface Combatants 

The Chinese People’s Liberation Army Navy (PLAN) surface combatant fleet in 2007 
consisted of some 27 destroyers and 47 frigates, plus a large number of guided missile boats, 
torpedo boats and patrol boats. Chinese destroyers fall into seven classes, listed from oldest to 
newest: Luda, Luhu, Lihai, Luyang, Luyang II, Hangzhou and Luzhou. The Luda represents the 
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bulk of the current Chinese destroyer fleet. However, it is being phased out in favor of the 
Luyang II, Hangzhou and Luzhou-class destroyers [Global Security.org, “Chinese Warships,” 
2008]. 

The threat assessment was focused on Hangzhou and Luzhou class destroyers, the two 
newest classes of destroyers. The Hangzhou class, pictured in Figure 15, is of interest because 
the Hangzhou class destroyers are Sovremenny-class destroyers purchased from the Russians. 
The Russian Sovremenny-class destroyers are considered to represent a more capable and 
balanced design than other Chinese warships. The Sovremenny-class destroyers carry the Top 
Plate D/E-band air search radar and the Palm Frond I-band surface search radar [Global 
Security.org, “Hangzhou Type 956 Specifications,” 2008]. The Sovremenny-class destroyers are 
equipped with SA-N-7 "Gadfly" or SA-N-17 "Grizzly" surface-to-air missiles (SAM). Both 
missiles are considered intermediate-range, with a range of 25 km [Global Security.org, 
“Hangzhou Type 956,” 2008]. Of more importance is that the Sovremenny-class destroyers 
carry the SS-N-22 Sunburn surface-to-surface missile. The Sunburn is a sea-skimming missile 
with a range of 161 km, a speed up to 4.5 mach and an active and passive radar seeker [Global 
Security.org, “Hangzhou Type 956 Specifications,” 2008] 
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Figure 15: Haizhou Type 956 Destroyer 

Hangzhou Type 956 destroyers are a surface threat interest. They are Russian Sovremenny class 
destroyers capable of carrying the SS-N-22 surface-to-surface missile. [From GlobalSecurity.org, 
“Haizhou Type 956 Pictures,” 2008] 


The Luzhou class is the newest Chinese destroyer. The Luzhou class is designed 
primarily for anti-air warfare. Little technical data is publically available on this ship class. 
However, for the purposes of this threat assessment, it is considered less of a threat than the 
Hangzhou class described above [Global Security.org, “Type 51C Luzhou DDG-X,” 2008]. 

Chinese frigates consist of four classes, listed from oldest to newest: Jianghu, Jiangwei I, 
Jiangwei II and Jiangkai. The Jianghu class is being phased out of the Chinese fleet with the 
new frigate construction focusing on the Jiangkai class, constituting all new frigate production 
[Global Security.org, “Chinese Warships,” 2008]. 

The Jiankai class will possess a limited anti-air warfare and surface warfare capability. 
With the addition of Russian Kamov Ka-28 anti-submarine warfare helicopters and an active and 
passive sonar system, the mission of the class is primarily anti-submarine warfare. As a surface 
threat, the Jiankai class design uses stealth shaping, comparable to the French Lafayette-class 
frigates [Global Security.org, “Jiangkai Type 054 Frigate,” 2008]. 
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The threat to U.S. naval platfonns is not limited to destroyers and frigates. The Houxin 
guided missile boats, which constitute the largest segment of China’s missile boat fleet, carry the 
YJ-1 surface-to-surface missile [GlobalSecurity.org, “Houxin Class (Type 037-IG / Type 343M) 
large missile boats,” 2008]. The YJ-1, also known as the C-801, is believed to be the result of 
reverse engineering of the Exocet missile. The missile has been demonstrated in tests to be able 
to sink a ship of 10,000 ton displacement and has a maximum effective range of 42 kilometers 
[GlobalSecurity.org, “C-801 YJ-1 / YJ-8 (Eagle Strike) / YJ-83 / CSS-N-4 SARDINE,” 2008], 

5. Unconventional Threats 
a. Fast Attack Craft 

Of major focus in the category of unconventional threats are small boats. These craft can 
travel up to 40-50 knots, are armed with 50 caliber machine guns and Rocket Propelled Grenades 
(RPG) and possibly more advanced weapons, are manned by a crew of 2-3 or higher depending 
on size and have a low RCS [Haas and Neel, 2008], Small boats can be divided into two 
categories: FAC and Fast Inshore Attack Craft (FIAC). 

FAC are small military vessels used by countries with established navies for patrol, 
enforcement, search and rescue and coastal defense. They are fast, maneuverable, capable of 
operating in relatively shallow waters, have a relatively small radar signature and can carry a 
variety of lethal anti-ship armament. They are used by countries with large navies and extensive 
coastline as well as smaller countries with negligible other naval assets [Office of the Chief of 
Naval Operations, 2007]. Examples shown in Figure 16 and Figure 17 include the Super Dvora 
and Roussen Class FACs and provide a sense of the size and maneuverability of the FAC-type 
vessels. 
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Figure 16: Super Dvora Fast Attack Craft 

The Super Dvora FAC is a small, highly maneuverable vessel well suited for operating in the 
littorals [From Office of the Chief of Naval Operations, 2007]. 



Figure 17: Roussen Class Fast Attack Missile Craft 

The Roussen Class is another example of a FAC; highly effective in the littorals [Naval 
Technology.com]. 


FIAC are militarized commercial boats that are capable of limited operations in near¬ 
shore coastal areas. As the nautical equivalent of “technicals” (pickup trucks with machine gun 
mounts used ashore in many third world nations), these vessels are small-signature, fast, 
economical, and can be pressed into service on short notice in large numbers. FIAC size can be 
as small as a personal watercraft, can be open or enclosed, and have a small crew. These craft 
are often capable of operating at speeds over 30 knots. FIAC have limited sensors, weapons, 
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payload, and fuel. FIACs are hard to detect because they blend with the coastal environment and 
it is difficult to ascertain their intentions. They are usually unarmored and depend on speed and 
surprise. When used in a mass attack, the time to detect and identify a FIAC as hostile can 
pennit enough time for the FIAC to get close and overwhelm a combatant’s defenses [Office of 
the Chief of Naval Operations, 2007]. Figure 18 provides an example of an alleged Iranian 
FIAC, illustrating both the size and manning of the vessel. 



Figure 18: Alleged Iranian FIAC 

This alleged Iranian FIAC was filmed by the USS Hopper in the Strait of Hormuz, 6 Jan 2008. It 
appears to be a pleasure craft type vessel that is being used for military purposes [Karl and 
Martinez, 2008]. 

FAC and FIAC are well suited for coastal defense where the crews know the waters well 
and can take advantage of shallows and concealment areas to launch short-notice surprise attacks 
against hostile naval units. In this role they can take advantage of inlets and coastal clutter for 
concealment, and shore-based Command, Control and Communications (C3) and ISR networks 
for support and coordination [Office of the Chief of Naval Operations, 2007; Haas and Neel, 
2008]. 

Defense against FAC and FIAC depends largely on an understanding of the threat, 
potential threat tactics, and own-force readiness. FAC are armed with a variety of conventional 
naval weapons including crew served and automatic naval canon and machine guns, surface-to- 
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surface missiles (SSM) and SAMs, torpedoes, RPGs and small arms [Office of the Chief of 
Naval Operations, 2007]. 

One of the most common RPGs is the Russian-made RPG-7, which has a maximum 
effective range of 500 meters for stationary targets and 300 meters for moving targets 
[GlobalSecurity.org, “RPG-7,” 2008], However, the use of a RPG from a moving platform 
makes effective use difficult [Haas and Neel, 2008]. A 0.50-caliber machine gun has a longer 
effective range, up to 1,830 meters for the U.S. M2 "Ma Duce" [GlobalSecurity.org, “M2 .50 
Caliber Machine Gun,” 2008]. However, employment from a moving ship will still require 
stabilization to be effective [Haas and Neel, 2008]. 

FIAC may be armed with a variety of weapons, from small arms and rocket propelled 
grenades, to anti-tank missiles and recoilless rifles. They can also be filled with explosives and 
used as waterborne IEDs either by remote control or with suicide crew [Office of the Chief of 
Naval Operations, 2007]. A platform smaller than a FIAC can also be employed as a Remotely 
Operated Vehicle (ROV). The ROV threat could include platforms as small as a jet ski [Haas and 
Neel, 2008], 

It is important to note that the goal of an unconventional attack is not necessarily to sink 
the platform. One goal that can impact overall force effectiveness is to cause sufficient damage 
to reduce a ship’s operational capability. This will force the ship to remove itself from battle, 
likely while drawing protection from another friendly platfonn(s). For example the ship’s radar 
arrays may be targeted specifically to reduce operational capability [Haas and Neel, 2008], 

b. Commercial Platforms 

Commercial ships serve a wide variety of purposes and thus vary greatly in size and form 
from extremely large commercial carriers to small size fishing vessels. Commercial ships can 
pose a risk to U.S. Navy ships if used as an unconventional attack platform. The use of a 
legitimate commercial ship for an attack will make positive identification challenging prior to the 
moment of attack. 

Lloyd’s Register classifies ships into the following categories: bulk carriers, container, 
cruise, gas, naval, ropax, tanker and yacht [Lloyd's Register, “Marine Ship Types,” 2008]. This 
analysis was focused on bulk carrier, tanker, container, and gas ships, as well as fishing vessels. 
Other types not discussed include tug, barge, and roll-on/roll-off ships. 
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Tanker and bulk carrier ships represent the largest portion of commercial deadweight 
tonnage, accounting for 36.9% and 36.0% respectively, of total commercial deadweight tonnage 
in 2006 [United Nations Conference on Trade and Development, 2006]. Tanker ships are 
designed to carry crude or refined oil products. Tanker ships range in capacity from 10,000 to 
550,000 deadweight tons (dwt), divided into the types seen in Table 6 [Global Security.org, 
“Tanker Types,” 2008], 


Table 6: Commercial Platform Sizes 

These common commercial vessels have large cargo capacities and can be used as unconventional 
threats to naval combatant ships. 


Class 

Size (deadweight tons) 

Handysize 

10,000-30,000 

Handymax 

30,001 -50,000 

Panamax 

50,001 -80,000 

(constrained by the locks of the Panama Canal) 

Aframax 

80,001 - 119,000 

Suezmax 

up to 150,000 

(constrained by the Suez Canal) 

Capesize 

over 150,000 

(must travel around Cape Horn or the Cape of Good Hope) 

Very Large Crude Carrier 
(VLCC) 

200,000 to 299,999 

Ultra Large Crude Carrier 
(ULCC) 

300,000 to 550,000 


Aker Philadelphia Shipyard builds the Veteran Class MT46, a tanker ship with a length 
of 183 meters, a draft of 12.2 meters, a deadweight tonnage of 45,800 tons, a speed of 14.6 
knots, a range of 14,000 nautical miles and a crew capacity of 32 [Aker Philadelphia Shipyard, 
“Veteran Class MT46 Product Tankers Data Sheet,” 2008]. 

Bulk carriers are designed to carry powders and grains that are stored in loose form. 
Cargo includes cement, grains and salt. Bulk carriers follow a similar type structure as ta nk ers 
[Global Security.org, “Bulk Cargo Carrier,” 2008]. 

Container ships continue to grow in size and quantity, growing in total deadweight 
tonnage by 13.3 percent in 2006. The average capacity of container ships was 2,324 twenty-foot 
equivalent units (TEUs) in 2006. However, new classes of container ships have capacities of 
over 9,000 TEUs with Maersk Line producing a mega ship with a capacity of 13,640 TEU 
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[United Nations Conference on Trade and Development, 2006]. One specific example, Aker 
Philadelphia Shipyard produces the Philadelphia CV2600 class container ship, with a length of 
217 meters, a draft of 12.5 meters, a deadweight tonnage of 29,400 tons, a speed of 22.5 knots, a 
range of over 10,000 nautical miles and a crew capacity of 26 [Aker Philadelphia Shipyard, 
“Philadelphia CV2600 Containership Data Sheet,” 2008]. 

Liquid Natural Gas (LNG) tankers are typically 259 meters in length and carry 120,000 
cubic meters of LNG. Natural gas is liquefied at minus 160 degrees Celsius and is stored in 
insulated tanks on the ship [Global Security.org, “Tanker Types,” 2008]. The effects of a LNG 
explosion are not well known. Industry officials claim that any explosion would be confined to 
the tanker. However, the potential exists for clouds of natural gas to escape and lead to “back 
bum,” or gas cloud fires well away from the LNG ship [Daniel, 2004]. 

Fishing vessels vary greatly depending upon the location. In Somalia, illegal fishing is 
rampant due to the lack of government enforcement. Fishing vessels from a variety of countries, 
Belize, France, Honduras, Japan, Kenya, Korea, Pakistan, Saudi Arabia, Spain, Sri Lanka, 

Taiwan and Yemen, work off the coast of Somalia. 

c. Criminal and Piracy Organizations 

Maritime piracy consists of any “illegal act of violence or detention committed for 
private ends against a ship, aircraft, or persons or property on board” a ship or aircraft 
“committed on the high seas” [Ameri and Shewchuk, 2008: 9]. Although the United Nations 
Convention on the Law of the Sea of 1982 distinguishes legally between piracy and robbery at 
sea, the two commonly are joined and many sources, including this summary, consider armed 
robbery at sea as one form of piracy [Ameri and Shewchuk, 2008]. 

Modern maritime piracy is an increasing threat to merchant and private vessels transiting 
or visiting certain regions of the world. Areas with widespread or severe poverty, failed 
governments and inadequate law enforcement have seen sharp increases in the number of 
reported incidents. Criminals in some areas have learned that it is possible to gain large rewards 
by robbing or ransoming undefended transient mariners. Governmental ineffectiveness or even 
complicity has propagated the trend. The International Maritime Bureau Piracy Reporting 
Center has reported “an unprecedented increase” in pirate activity for the first three quarters of 
2008, with a total of 199 incidents. These incidents include 115 vessels boarded, 31 hijacked 
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and 23 fired upon. Five hundred eighty-one crewmembers were taken hostage, nine kidnapped, 
nine killed and seven missing and presumed dead. Almost a third of the incidents occurred in the 
waters near Somalia, with 12 vessels and 250 crew still held captive as of 30 September 2008. 
Nigeria was second in tenns of numbers of reported incidents (24), mostly in the Lagos region, 
but a significant percentage of Nigerian incidents go unreported. Indonesia ranked third in 
numbers of attacks (23). Both Indonesia and the formerly hot Malacca Straits have both seen 
piracy decrease recently. Other persistent regions of activity include the Indian Ocean, Southeast 
Asia, and South America [ICC-Commercial Crime Services, 2008]. 

Other forms of criminal activity pose less of a threat to naval forces but still impact the 
course of United States naval operations. Sanction enforcement, counter-proliferation activities, 
protection of human rights (trafficking in persons), anti-drug operations, and counter-terrorist 
patrols each bring Navy personnel in contact with hostile forces with incentive and potential 
means to resist forcefully. 

The modus operandi of pirate attacks includes covert boarding of anchored vessels at 
night, or pursuit in small boats and boarding with grappling hooks and ladders by day. Weapons 
can range from knives and machetes to military small arms and RPGs. A typical scenario after 
boarding includes robbing the crew and stripping the vessel of anything of value and, particularly 
around Somalia, kidnapping the crew, ship and cargo for ransom. Vessels attacked range from 
small private yachts to large container ships and bulk cargo carriers. Most pursuit attacks occur 
in daylight and at speeds averaging about 15 knots [Office of Naval Intelligence, 2008]. 

The threat to naval vessels is minimal when the pirates are unchallenged, but during 
enforcement activities the intercepting vessel can expect to be fired upon. On March 18, 2006 
the USS Cape St. George’s (CG 71) topsides sustained light damage from small arms fire while 
performing maritime security operations in international waters off the coast of Somalia. USS 
Gonzalez (DDG 66) and Cape St. George spotted and prepared to board a suspicious vessel 
towing two skiffs, when the suspected pirates opened fire with small anns. The Navy ships 
returned fire killing one suspect, burning the vessel to the waterline, and capturing the twelve 
surviving suspects [United States Naval Forces Central Command (NAVCENT) Public Affairs, 
2008], 

Threats expected from other forms of criminal activities, if any, would most likely be 
some form of resistance against boarding parties using individual weapons. However, 
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interdiction of a terrorist activity could result in a suicide ramming attempt or use of their vessel 
as a maritime delivered IED [Office of the Chief of Naval Operations, 2007]. 

6. Threat Signatures 

From the stakeholder analysis, a user need was identified to be able to classify and 
identify tracks using all available sensor sources. The possible threat signatures that can be used 
by the C2 system in support of classification and identification include radar, EO/IR, electronic 
support (ES) and acoustic. Each threat type will have the potential to have signatures that can be 
detected by the above sensor sources. 

Radar Cross Section (RCS) data varies based on azimuth, radar frequency and Swerling 
case, but can be roughly quantified for the threats addressed above. The RCS for a small boat or 
FIAC will be on the order of 0.02 m [Payne, 2006]. One can reasonably expect that the RCS for 
a smaller size ROV will be even smaller. For surface combatants, including the guided missile 
boat and destroyer threats and commercial ships, the RCS is approximately equal to the 
displacement tonnage expressed in m [Payne, 2006]. For the Haizhou class destroyer, the RCS 
is approximately 7,500 m . For the Houxin class guided missile boat, the RCS is approximately 
500 nr [Payne, 2006]. 

The EO, IR, ES and acoustic signatures of different ships are unique and can only be 
discussed generally in this assessment. EO detection is a function of the environment and is 
based on the amount of visual contrast. The IR signature of a ship is driven by the exhaust points 
and the temperature contrast of the ship’s exterior surfaces with its background, both of which 
are thermal sources. The ES signature of a ship is driven by the ship’s RF emitters, including 
navigation radar, and communications systems. The acoustic signature of a ship consists of a 
mix of narrowband and broadband sources. Machinery is the primary narrowband acoustic 
source for a ship. Flow and cavitations are broadband acoustic sources and are a function of the 
ship’s speed [Payne, 2006]. 
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7. Threat Assessment Conclusions 


The threat assessment reviewed an array of threats, ranging from the FAC and FIAC 
threats to conventional naval combatants and commercial vessels. The threats facing U.S. Navy 
platforms include a wide range of threat sizes, speeds, threat systems capabilities and 
employment techniques. 

The threat assessment identified five major types of threats from the above mentioned 
threat categories: ROV, small boats and FIAC, guided missile boats, destroyers and commercial 
vessels. The ROV threat is specifically treated as an IED. The small boat threat would be 
crewed and used in a coordinated, massed attack. Both threats present the same challenge of 
employment in constrained areas where the threat can use the environment and local ship traffic 
to screen intentions [Haas and Neel, 2008]. Commercial vessels present a threat primarily when 
they are utilized as a platform for attack or as an IED, similar to the ROV or FIAC threat but on a 
much larger scale [Office of the Chief of Naval Operations, 2007]. 

Conventional threats present similar challenges in that they can range greatly in size, 
from guided missile boats to destroyer-size platfonns. However, the threat systems with the 
greatest range continue to be the ASCM, which will range in capability up to 160 kilometers 
[Global Security.org, “Hangzhou Type 956 Specifications,” 2008]. 

Table 7 summarizes some of the key characteristics of those threats and some of the 
specific challenges associated with the management of those threats. 
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Table 7: Summary of Threat Parameters 

This table contains a summary of the threats and their related characteristics identified during the 
Threat Analysis. 


Type 

Size 

Maximum 

Speed 

Threat Systems 
& Range 

Challenges 

ROV 

Comparable to 
jet-ski 

40-50 kts 

IED 

Low RCS ; Blend in 
environment 

Small Boat & 
FIAC 

Comparable to 

recreational 

watercraft 

40-50 kts 

RPG: 300-500 m 

50 cal: 1,830 m 

Massed attack; Low 
RCS; Blend in 
environment 

Guided Missile 
Boat (PLAN 
Houxin class) 

62 m length 

7.2 m beam 

32 kts 

YJ-l/C-801: 42 
km 

Small; extended 
range threat 

Destroyer 
(PLAN Haizhou 
class) 

156.4 m length 
17.2 meters 
beam 

32 kts 

SS-N-22 

Sunburn: 161 km 

Multi-mission 
surface combatant 

Commercial 

Vessel 

Can be over 

200 m 

15-25 kts 

RPG, 50 cal, IED 

Difficult to identify 


The information gathered during the threat assessment, including threat types, 
signatures, speeds, weapon systems and ranges, have some applicability to the definition of the 
C2 system requirements. The threat information summarized in Table 7 provided inputs to 
requirements development, which will be discussed in Section III. A. of this report. However, the 
specific threats and their parameters have more applicability to the definition of sensor and 
weapon system requirements for naval platfonns. For example, the RCS of a personal watercraft 
does not affect the C2 system’s required perfonnance. The personal watercraft’s RCS is of 
substantial import to the definition of sensor system requirements, which are outside the scope of 
this effort. 

The threat assessment reinforces some key stakeholder requirements, including the need 
to integrate off-board sensors [Haas and Neel, 2008] and to utilize all available sensor data [Haas 
and Neel, 2008]. The over-the-horizon engagement ranges for enemy missile systems, such as 
the SS-N-22 and the YJ-1, highlight the need to utilize off-board sensors to extend the ship’s 
detection range. The small RCS for FIAC and FAC vessels underline the need to exploit all 
available sensors to detect, classify, and identify the vessels as detections solely off radar data 
alone will be challenged by the small RCS. 
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III. FUNCTIONAL ANALYSIS 


Requirements and architecture products were produced in the Functional Analysis phase. 
Using the information gathered during the Needs Analysis phase, the value system design and 
requirements definition tasks developed the system requirements. The enterprise architecture 
then modeled the system functionality required to satisfy the requirements. Through this phase, 
previous tasks were revisited to determine if stakeholder inputs were needed for clarification, if 
mission threads were adequately defined, and if the threat assessment was fully established. 

A. REQUIREMENTS DEFINITION 

1. Background 

The requirements definition task sought to translate stakeholder needs and objectives from 
the Needs Analysis phase into functional requirements descriptive of a C2 activity, and to 
allocate these requirements into a functional architecture capable of perfonning that activity. 
When possible, realistic or plausible operational constraints, measures of effectiveness, and 
measures of perfonnance thresholds were identified and associated with those functions. 

2. Methodology 

The products of the preceding Needs Analysis phase, specifically the stakeholder analysis 
and mission thread definition were used as inputs to the requirements definition task. 
Unclassified Joint and Naval doctrine publications were researched to expand upon the guidance 
provided by the stakeholders about user needs, to provide context to the mission areas, and to 
provide insight into how the SUW and MIO mission areas would be performed. The derived C2 
functions specific to the mission areas were initially compiled in a Dynamic Object-Oriented 
Requirements System (DOORS) database for configuration control and tracking purposes. 
DOORS is a commercially available requirements management software tool. This data was 
eventually migrated to a CORE file for commonality with the modeling tool intended to be used 
to validate the identified functions. 

The output was a hierarchy of C2 functions with their associated requirements and metrics. 
These functions are listed in the table in Appendix C, “C2 Requirements, VSD and Architecture 
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Matrix” and described below. Traceability of those requirements to source doctrine publications 
was also recorded. 

3. General Results 

A total of 77 functional requirements, 29 perfonnance requirements and 12 constraints were 
derived from the stakeholder surveys and feedback, from the mission thread activity analysis, 
and from the doctrine publication research. Functional requirements describe what the system 
must be able to do. Performance requirements describe how well the system must perform. 
Constraint requirements describe other operational or design limitations with which the system 
must comply. The requirements address the command and control functions of surface warfare 
in general, such as maintaining surface situational awareness, evaluating contacts and developing 
engagement orders, plus the specific additional requirements necessary for the MIO mission, 
such as C2 support for conducting visits, boarding, searches and seizures, and for reporting. 
Throughout the process, it was discovered that detection, tracking, and reporting functionality 
was common for the MIO and SUW threads. Since many of the tactical picture requirements 
and evaluation needs are common to both combat and non-combat situations, the majority of the 
requirements make no distinction between MIO and SUW. This helped avoid generating a set of 
redundant requirements due to the artificiality of segmenting along mission lines. 

The requirements are listed in Appendix C, along with the perfonnance measures developed 
during the VSD stage. Table 8 illustrates a short excerpt of this appendix. Each requirement is 
tracked by number in a hierarchical anangement in which higher level requirements are 
decomposed into multiple lower level requirements, as indicated by the number of decimal 
points in the requirement number. (Requirement 1.2 decomposed into 1.2.1, 1.2.2, etc.) 
Following each requirement statement is the source information for that requirement, and may be 
attributed to a Joint or Navy publication, a stakeholder, or another doctrinal source. 
Requirements that do not reference an external source were derived as necessary to ‘fill in’ the 
architecture when required. The Type column indicates whether a requirement is a functional or 
performance requirement, or a constraint. The Value System Design column further describes 
the requirement in terms of the intended objective and Measures of Performance or Effectiveness 
as described in the following section. 
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Table 8: C2 Requirements and VSD 

This table contains a partial listing for illustration purposes. For full listing of the C2 requirements 
and VSD refer to Appendix C. 


Requirement 

Rationale 

Type 

Value System Design 

1.2 Collect Target Information 

The C2 system shall collect target 
information for detecting, 
identifying, locating, and 
classifying targets. 

NTA 2.2.1 

Functional 

Obj: Determine C2 capability of sensors to 
identify an object under varied noise, weather, 
terrain conditions 

Performance Measure: Ability of sensors to 
identify an object under varied noise, weather, 
terrain conditions 

Goal: Probability of detection and classification 
>99% 

1.2.1 Receive Sensor Inputs 

The C2 system shall utilize radar, 
electro-optical/infrared (EO/IR), 
electronic surveillance (ES), 
identification friend-or-foe (IFF) 
and automatic identification system 
(AIS) data in the classification and 
identification of contacts. 

Goddin, 
2008; Flaas 
& Neel, 

2008 

Functional 

Obj: Assess C2 functionality in receiving data 
from sensors in detection, ID, and classification of 
contacts. 

PERFORMANCE MEASURE: Ability of C2 to 
correctly and accurately detect, Identify, classify 
contacts from sensor data 

Goal: Probability of correct detection, ID, and 
classification >85% 


One of the lessons learned when the functions were evaluated for timing requirements 
against specific threats was that in the SUW role, the timing was either non-stressing or overly 
so, with little middle ground. Engagement timelines necessary to counter representative threats 
described in the Threat Analysis (Section II. C.) phase of this report were calculated, using the 
threat’s expected detection range, closure rate and a mandatory safety range. These timelines, 
expressed in minutes or seconds, reflect the amount of time the ship had to detect and collect 
target information, process and engage the target, before it became vulnerable to enemy fire. A 
timeline allowance of zero seconds indicated a threat that was capable of launching a weapon 
against our ship at or beyond our ship’s detection range of the enemy. Mandatory safety range 
was the maximum range at which the threat could launch a weapon against our ship. Detection 
range was a function of the height above the sea surface of the threat, which determined the 
range at which it would be detectable above the radar horizon in nominal RF propagation 
conditions. The parameters used in these calculations are shown in Table 7, “Summary of Threat 
Parameters.” For example, in an encounter with a low capability surface platform that must close 
to within hundreds of yards or a mile of the ship, such as a FIAC, the ship had several minutes to 
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detect, assess, decide and act against the threat. However, against a peer-capability such as a 
missile anned destroyer capable of launching an ASCM from beyond the horizon, the capability 
of engaging in a surface warfare “shoot the archer” mode was essentially non-existent. The 
friendly ship must engage the ASCM in an air defense role, unless it can get a shot against the 
enemy vessel several minutes before the enemy can detect own ship and launch a missile. Thus, 
the SUW engagement timeline was typically either zero seconds against a missile ship or about 
15 minutes against a FI AC/FAC. 

This 15 minute timeline represented the time it would take a fast surface vessel to close the 
distance between the horizon and the ship assuming the ship does not contribute to or mitigate 
the threat’s rate of closure by high speed transit toward or away from the threat. This 
engagement timeline would be allocated across several of the perfonnance measures listed in 
Appendix C, “C2 Requirements,” principally requirements 1.2 (Collect Target Information), 1.3 
(Process Targets), and 1.4 (Localize Target), and their sub-elements. Although notional values 
were assigned to several of these perfonnance measures, different allocations of time would be 
acceptable as long as the total timeline constraint is achieved. These measures collectively 
constitute the trade space. 

B. VALUE SYSTEM DESIGN 

1, Background 

The Value System Design (VSD) is a hierarchy of objectives, functional requirements, 
Performance Measures (PMs), and their goals. Buede defines a VSD as a hierarchy of objectives 
that are important to the system’s stakeholders [Buede, 2000]. The VSD is a process and a 
product that identifies stakeholder objectives and ties them to requirements. The VSD results in a 
product that traces the objectives to the requirements and the development of PMs and their 
associated goals. These goals and metrics add value and meaning to what each functional 
requirement entails. In short the VSD is the bridge between the Needs Analysis and Functional 
Analysis by connecting the stakeholder’s objectives to the requirements definition phase. 
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2. Methodology 

The VSD effort was conducted in parallel with the requirements development. The VSD 
took the approach of identifying the objectives defined in the stakeholder analysis and mapping 
those objectives to respective functional requirements defined in the requirements definition. 
Performance and Constraint requirements were not the focus of the VSD, as these requirements 
identified in the Requirements Definition phase directly represent PMs and goals self-contained 
within these requirements. Although the VSD was not focused on the performance and 
constraint requirements, the VSD maintained the general hierarchy that was developed in the 
requirements definition. It is through the use of this hierarchy that the VSD was able to maintain 
configuration management in respect to the work done on the requirements definition. In 
addition, the VSD was able to determine several requirements that could be grouped within a 
single objective, which those groups of requirements could be addressed by one or two PMs and 
their respective goals. 

PMs on the other hand were derived from a combination of mapping the objectives to the 
requirements and in addition from supplemental information derived from the Mission Threads 
and Threat Assessment. In short the VSD’s PMs were pieces of information, values, and 
concepts taken from each of the respective sections discussed above. The PMs were identified to 
assess each requirement to detennine how well they meet mission requirements, stakeholder 
objectives, and associated Navy doctrine and publications. It is through the interfacing of these 
sections together that the PMs could be derived. In other cases, PMs were directly taken from 
Navy Doctrine and Pubs. 

The representative PM goals and values were based upon information from the 
stakeholder’s analysis, Navy doctrine and publications, and the Navy Task List. In some cases, 
PM goals were not included in order to maintain the project at an unclassified level. In these 
cases the goals were derived for these particular PMs. The results of the VSD were organized 
into a tabular format to demonstrate how requirements fed into the stakeholder objectives and 
lastly how PMs were derived with their associated goals. The VSD alongside with the 
requirements can be found in Appendix C. 
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3. Conclusion 


A total of 77 functional requirements were identified in the requirements definition 
phase. Of those 77 requirements, 23 requirements were consolidated to support the same 
objectives, PMs, and goals. The remaining 54 functional requirements were addressed with 
distinct objectives, PMs, or derived values. What this means is that a majority of the 
requirements defined in the requirements definition phase had distinctive PMs and goals 
assigned to them and that these results could be traced back to the stakeholder objectives. 

The VSD essentially provided evidence in mapping and tracing the stakeholders’ 
objectives to the requirements and the requirements to the PMs and their associated values. The 
VSD validated and verified that the requirements definition phase captured the stakeholder 
objectives. In addition the VSD provided PMs and goals that can be utilized for further study. 

C. ENTERPRISE ARCHITECTURE 

1. Background 

The enterprise architecture task defines the required behavior of the C2 system, the 
operational activities that the C2 system must support, and the functionality of the C2 system 
itself. The operational activities are based on current SUW and MIO doctrine identified during 
the Stakeholder Analysis task of the Needs Analysis phase. The operational activities reflect the 
tasks that must be completed in support of the missions identified in the Mission Thread 
Analysis, independent of their implementation in specific systems. The C2 system functionality 
defines what the C2 system is required to do and the interfaces with external systems that the C2 
system must support. The enterprise architecture implements key inputs from the stakeholder 
analysis, namely the concepts of Distributed Weapons Coordination (DWC) and Engage on 
Remote (EOR). 

DWC is implemented in the architecture through common algorithms for threat 
evaluation and engagement scheduling and the sharing of effectiveness data between platforms. 
In essence, each platfonn executes a common algorithm for threat evaluation. Based on the 
resultant common threat list, each platform exchanges engagement effectiveness estimates with 
other platforms. The engagement effectiveness inputs feed a common engagement scheduling 
algorithm, leading to common engagement assignments across the force. 
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EOR capability permits a ship to engage targets being tracked by other platforms, rather 
than solely those for which it has its own sensor data. Since each platform shares the same 
contact report inputs and the same tracking algorithms, this contributes to a common track 
picture between platforms. Once the common track picture has been developed, remote tracks 
and organic (own ship) tracks can be addressed on an equal basis, with no outward difference to 
the system operator. This pennits the most capable and best situated sensor(s) and the most 
capable and situated weapons system to be utilized, even if they are not on the same platform. 

Also, during the architecture task, requirements were allocated to the system’s functions. 
The allocation process ensured that all requirements could be mapped to at least one function, 
meaning that the architecture addressed all of the C2 system requirements. The allocation 
process also ensured that all functions were allocated at least one requirement, meaning that all 
included C2 system functionality supported a system requirement. In cases where the allocation 
of requirements to the system functions was not complete, the architecture task fed the 
discrepancies back into the requirements definition to clarify the C2 system requirements. A 
specific example of the feedback to the requirements task includes the identification of three 
previously undocumented requirements: to allow the user to tailor the display, to receive and 
process the OPTASK LINK and to support the querying of commercial ships in support of MIO. 

2. Methodology 

The DoDAF was used to describe the architecture for both the SUW and MIO missions. 
The framework defines three related views of the architecture: operational view (OV), systems 
view (SV), and technical standards view (TV). Due to the scope of this project, only the OV and 
SV were used. In addition to the OV-1 diagrams presented earlier in this report, three other 
DoDAF products were created: the operations activity model (OV-5), the system functionality 
description (SV-4), and the operational activities to systems function traceability matrix (SV-5). 
The OV-5 was created to show the capabilities, operational activities, relationships among 
activities, and inputs and outputs to the operational activities. The SV-4 shows the system 
functionalities and data flow among the system functions. The SV-5 shows show the mapping of 
system functions to the operational activities. 

In the development of the OV-5 and SV-4 products, the CORE Systems Engineering tool 
was used to document and integrate the products. CORE allows the use of either the Integration 
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Definition language 0 (IDEFO) or the Enhanced Functional Flow Block Diagram (EFFBD) 
methods for functional modeling. IDEFO was specifically chosen as a language because it 
supports a good representation of concurrent systems that do not demonstrate sequential 
behavior. IDEFO shows the tasks and information flows within a system. An IDEFO diagram 
shows the inputs, controls, outputs, and mechanisms (ICOMS) for an activity or function. An 
input is an object that is changed as a result of the activity or function. A control is an object that 
guides or regulates the activity or function. An output is an object that is the result of the activity 
or function. A mechanism is a system, organization, people, etc. that support or perform the 
activity or function [National Institute of Standards and Technology, 2009]. The OV-5 and SV-4 
diagrams below do not include any mechanisms. The architecture is intended to define the 
required functional behavior of the C2 system and not the design of the physical system itself. 

During the development of the OV-5, the NTTL was referenced for operational activities 
[Office of the Chief of Naval Operations, 2007]. There were some specific cases where the 
activities defined were not directly taken from the NTTL. These cases were whenever there was 
an activity specific to the architecture that needed to be defined that was not clearly included 
within the NTTL. 

The OV-5 development was also based upon the SUW and MIO mission threads defined 
in Section II.B “Mission Threads Analysis.” Key concepts of classification, identification, 
application of ROEs, input of weapon status, commercial ship queries, issuance of the 
engagement order and engagement assessment were translated directly into the OV-5. However, 
the OV-5 goes into greater detail than the mission threads in certain areas, specifically in the 
exchange of data via the track file, further decomposition of guidance such as ROE into 
preplanned responses, classification and identification criteria, weapons release criteria and 
expansion of external inputs such as intelligence data and Operation Tasks (OPTASK). 

During the development of the SV-4, the Surface Navy Combat Systems Product Line 
Software Architecture: Architecture Description Document [Program Executive Office for 
Integrated Warfare Systems, 2008] was used as the source for the top-level functions, where the 
top-level functions map to the domains within the document. As with the OV-5, top-level 
functions were added as necessary when specific functionality needed to be called out that was 
not present within the Architecture Description Document at the domain level. 
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3. Architecture Products 


The following diagrams represent the architecture for the C2 system. Figure 19 through 
Figure 22 and accompanying descriptions pertain to the OV-5 for the C2 system. Figure 23 is 
the external system diagram. Figure 24 through Figure 27 diagrams and descriptions pertain to 
the SV-4. Finally, the SV-5 is shown in Table 9. 

a. Operational Activities 

Perform C2 consists of three operational activities: Collect Target Information (NTA 
2.2.1), Process Targets (NTA 3.1) and Maintain Information and Naval Force Status (NTA 
5.1.3). The OV-5 AO diagram for Perform C2 is shown in Figure 19. 



Figure 19: OV-5 AO Diagram for Perform C2 


The OV-5 AO Diagram contains three operational activities: Collect Target Information, Process 
Targets, and Maintain Information and Naval Force Status. 

The first operational activity is “Collect Target Information,” which encompasses the 
tracking, classification, and identification of surface contacts. This activity uses, contact reports 
from external sensors, external track files, ship self-identification data from AIS, intelligence 
data as inputs, query responses from surface contacts. As controls, this activity uses the set of 
internally maintained track files and the classification and identification criteria. This activity 
outputs a query to a surface contact, new track file, or a track file update. 

The second operational activity is “Process Targets,” which includes the selection of 
targets, the allocation of targets to weapons, and the issuance of the order to engage. This 
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activity uses weapons status and external engagement effectiveness estimates as inputs and 
outputs an order to fire, external engagement effectiveness estimates, boarding order, and track 
file updates indicating engagement status on the track. The controls for this activity are the 
weapons release criteria, the set of internally maintained track files, and the pre-planned 
responses. 

The third operational activity is “Maintain Infonnation and Naval Force Status,” which 
provides for the maintenance and display of the tactical picture, unit status, and force command 
and coordination status. This activity uses track file updates, new track files, intelligence data to 
maintain the tactical picture, and weapons, boarding, and sensor statuses to maintain unit status 
as inputs. The controls for this activity are the operation tasks (OPTASKs) LINK, MIO SUPP, 
and SUW. OPT ASK LINK is the information required to establish the link network. OPT ASK 
MIO SUPP describes the authority required to conduct each MIO task, rules of engagement, the 
format and frequency of situation reports (SITREPs), and any other specific required procedures 
during boarding. OPTASK SUW describes authorities, rules of engagement, reporting 
requirements, and other infonnation required to conduct SUW operations. This activity outputs 
track files, the boarding communication plan (COMPLAN), and SITREPs to external commands. 
It uses the OPTASKs to produce a number of additional outputs that are controls for other 
activities, including the set of internal track files, weapons release criteria, pre-planned 
responses, and classification/identification criteria. 

The “Collect Target Information” operational activity is decomposed into three sub¬ 
activities as shown in Figure 20. These sub-activities include the following: Track Contacts, 
Classify Contacts, and Identify Contacts. 
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Figure 20: OV-5 A1 Diagram for Collect Target Information 

This figure is the decomposition of the “Collect Target Information” activity. 


The first sub-activity is “Track Contacts,” which accepts inputs of contact reports from 
both own-ship and external systems as well as external track files. An internally maintained 
track file provides the control for this activity. The Track Contents activity utilizes these inputs 
to create an update to the internal track file, along with an output of a new external track file. The 
use of both own-ship and external contact reports in the generation of new track files and track 
file updates implements the EOR capability. 

The second sub-activity is “Classify Contacts,” which requires the internal track file and 
classification and identification criteria as controls. These controls allow the activity to output a 
track file update with the classification parameters added. 

The third sub-activity is “Identify Contacts,” which requires ship self-identification data 
from AIS, intelligence data, and query responses as inputs in conjunction with the internal track 
file and classification/identification criteria controls. This activity uses these outputs as a query 
to a surface contact and outputs a track file update with the identification parameters added. 

The “Process Targets” operational activity is decomposed into six sub-activities as shown 
in Figure 21. These sub-activities include the following: Request Attack, Select Target to 
Attack, Select Platform(s) and System(s) for Attack, Develop Order to Fire, Conduct Tactical 
Combat Assessment, and Select Ship to Visit, Board, and Search. 
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Weapons Release Criteria 



► Engagement Effectiveness Estimate 


► Track File Update 

► Order to Fire 


Figure 21: OV-5 A2 Diagram for Process Targets 


This figure is the decomposition of the “Process Targets” activity. 


The first sub-activity is “Request Attack,” which utilizes the controls of weapons release 
criteria, pre-planned responses, and track files to develop a target nomination. This target 
nomination is output directly into the second sub-activity, “Select Target to Attack.” The “Select 
Target to Attack” sub-activity utilizes this input and the same controls as the first sub-activity to 
select a target, which is an output to the third sub-activity, “Select Platform(s) and System(s) for 
Attack.” These two activities employ a threat evaluation algorithm that is common across the 
force in support of Distributed Weapons Coordination. 

The “Select Platform(s) and System(s) for Attack” sub-activity utilizes target selection, 
weapons status, and external engagement effectiveness estimates as inputs. As controls, this 
activity uses the weapons release criteria and pre-planned responses. This activity outputs own- 
ship engagement effectiveness estimates and uses both own-ship and external engagement 
effectiveness estimates when executing an engagement scheduling algorithm that is common 
across the force to support DWC. This activity creates a weapon assignment. 
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The fourth sub-activity is “Develop Order to Fire,” which requires the weapon 
assignment as an input and the pre-planned responses as a control. This activity uses these 
inputs to generate an order to fire and a track file update. 

The fifth sub-activity is “Conduct Tactical Combat Assessment,” which requires no 
input, but uses the track file as a control. Additional information is added to the track file, which 
leads to a track file update output. 

The sixth sub-activity is “Select Ship to Visit, Board, and Search,” which requires no 
input and uses the track file as a control. This activity may output a boarding order, if a ship is 
selected to visit, board, and search. Obviously, this activity is distinct to a MIO activity and 
would not be activated in an engagement scenario. This sub-activity within the Process Targets 
activity reinforces the concept that the OV-5 is a common functional set that can be applied 
across both the SUW and MIO mission threads and all activities may not be applicable in all 
scenarios. 

The “Maintain Information and Naval Force Status” operational activity is decomposed 
into three sub-activities as shown in Figure 22. These sub-activities include the following: 
Maintain and Display Tactical Picture, Maintain and Display Force Command and Coordination 
Status, and Maintain and Display Unit Readiness. 
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Figure 22: OV-5 A3 Diagram for Maintain Information and Naval Force 
Status 


This figure is the decomposition of the “Maintain Information and Naval Forces Status” activity. 
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The first sub-activity is “Maintain and Display Tactical Picture,” which requires 
intelligence data, a new track file, and a track file update as inputs. This activity uses these 
inputs along with link settings from the second sub-activity, “Maintain Display Force Command 
and Coordination Status,” as a control to create track files and tactical picture metrics. 

The “Maintain and Display Force Command and Coordination Status” sub-activity 
requires OPTASKs LINK, MIO SUPP, and SUW as controls to generate and output the li nk 
settings required in the “Maintain and Display Tactical Picture” sub-activity and to output 
classification and identification criteria, a boarding COMPLAN, weapons release criteria, and 
pre-planned responses. 

The third sub-activity is “Maintain and Display Unit Readiness,” which utilizes the 
tactical picture metrics from the “Maintain and Display Tactical Picture” sub-activity, along with 
sensor, weapon, and boarding statuses as inputs. This activity uses the OPTASK LINK, 
OPTASK MIO SUPP, and OPTASK SUW as controls. This activity uses these inputs and 
controls to generate SITREPs. 

b. Functional Descriptions 

The C2 system must interface with other own-ship and external systems or entities. An 
external system diagram shows the external systems and entities that the C2 system interfaces 
with and the data flows between them. The external systems are: intelligence agency, own-ship 
sensor systems, SUW Commander (SUWC) or MIO combat operations center (COC), other 
platform sensor and C2 systems, commercial ships, own-ship weapons systems, and boarding 
party. The A-l external system diagram for Perform C2 is shown in Figure 23. 
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Figure 23: A-1 External System Diagram for Perform C2 

This is the context diagram for the Perform C2 Function and depicts the external systems with 
which the C2 system interacts. 


Perform C2 consists of four functions: Display Tactical Data, Perform Track 
Management, Conduct Combat Control, and Report Status. The SV-4 AO diagram for Perform 
C2 is shown in Figure 24. 


65 





Figure 24: SV-4 AO Diagram for Perform C2 

The SV-4 AO Diagram contains four operational activities: Display Tactical Data, Perform Track 
Management, Conduct Combat Control, and Report Status. 

The first function is “Display Tactical Data,” which includes displaying tactical data and 
various statuses. This function uses boarding, sensor, and weapon statuses and tactical picture 
metrics as inputs. As controls, this function uses the following: the set of internally maintained 
track files from the second function “Perform Track Management,” OPTASKs LINK, MIO 
SUPP, and SUW, airspace coordination orders, and friendly and neutral ship locations. This 
function does not have any outputs. The “Display Tactical Data” function produces the display 
as output to the system operator. The decision was made to leave the display output off the 
diagram as it was inconsistent with outputs such as Track Files that represent data exchanged 
between functions. 

The “Perform Track Management” sub-function consists of the formation, classification, 
identification, correlation and decorrelation, and bearing and fix association of tracks. This 
function uses several inputs: ship self-identification data from AIS, contact reports from external 
sensors, electronic warfare (EW) bearings, external track files, intelligence data, query responses, 
and track file updates from the third function “Conduct Combat Control.” The controls for this 
function are the link settings and classification and identification criteria from the “Conduct 
Combat Control function.” This function outputs track files, which the “Display Tactical Data” 
function also uses as a control, and tactical picture metrics, which is an input to the “Display 
Tactical Data” function. 
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The third function is “Conduct Combat Control,” which includes assessing and 
prioritizing threats, issuing engagement or boarding orders, and assessing the engagement. This 
function utilizes weapon status, environmental data, and external engagement effectiveness 
estimates as inputs. The controls for this function are the same as the ones used by the “Display 
Tactical Data” function. Track files are represented as a control and not as an input because they 
guide how the function prioritizes threats, issues orders and assesses engagement. However, the 
track files are not directly modified by the function during execution. Track file updates are 
produced and incorporated into the track files within the Track Management function. The 
“Conduct Combat Control” function has several outputs: link settings and classification and 
identification data, which are used as controls by the “Perform Track Management” function, 
sensor plans, order to fire, queries, boarding orders, boarding COMPLAN, and track file updates, 
which are used as an input by the “Perform Track Management” function. The “Conduct 
Combat Control” function also exports engagement effectiveness estimates in support of the 
Distributed Weapons Control concept. 

The fourth function is “Report Status,” which includes the sending of SITREPs to higher- 
level commands. This function used boarding, sensor, and weapon statuses as inputs. The 
controls for this function are OPTASKs MIO SUPP and OPTASK SUW. This function utilizes 
these inputs and controls to generate SITREPs. 

The “Display Tactical Data” function is decomposed into five sub-functions as shown in 
Figure 25. These sub-functions include the following: Provide Tactical Display Configuration 
Options, Display Track Data, Display Engagement or VBSS Status, Display Sensor Status, and 
Display Command Data. 
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Figure 25: SV-4 A1 Diagram for Display Tactical Data 

This figure is the decomposition of the Display Tactical Data function. 


The first sub-function is “Provide Tactical Display Configuration Options,” which does 
not have any inputs, but uses the display output from the four display functions as a control. The 
display output serves as a control to the “Provide Tactical Display Configuration Options” 
function because the function does not directly modify the display. Rather, the function provides 
display setting to the various display functions. This function outputs display configuration 
settings, which are used as a control for the four display functions. 

The second sub-function is “Display Track Data,” which uses tactical picture metrics as 
an input. The controls for this function are the display configuration settings from the “Provide 
Tactical Display Configuration Options” function, airspace coordination order, friendly and 
neutral ship locations, and track files. This function provides the display component for track 
data. 

The third sub-function is “Display Engagement/VBSS Status,” which uses weapon and 
boarding statuses as inputs. The controls for this function are the display configuration settings 
from the “Provide Tactical Display Configuration Options” function and track files. This 
function provides the display component for VBSS and engagement status data. 


68 




The fourth sub-function is “Display Sensor Status,” which includes sensor status as an 
input. The control for this function is the display configuration settings from the “Provide 
Tactical Display Configuration Options” function. This function provides the display component 
for sensor status. 

The fifth sub-function is “Display Command Data,” which does not have any inputs, but 
uses OPTASK LINK, OPTASK MIO SUPP, and OPTASK SUW and the display configuration 
settings from the “Provide Tactical Display Configuration Options” function as controls. This 
function provides the display component for command data, such as the OPTASKs. 

The “Perform Track Management” function is decomposed into seven sub-functions as 
shown in Figure 26. These sub-functions include the following: Store and Report Tracks, Form 
Tracks, Classify Tracks, Identify Tracks, Correlate and Decorrelate Tracks, Associate Bearings 
and Fixes to Tracks, and Manage Track Numbers. 



Figure 26: SV-4 A2 Diagram for Perform Track Management 

This figure is the decomposition of the Perform Track Management function. 


The first sub-function is “Store and Report Tracks,” which uses external track files, track 
file updates from the six other sub-functions, and new track files from the second sub-function, 
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“Form Tracks,” as inputs. The control for this function is the link settings. This function outputs 
tactical picture metrics and track files that are used as controls by the six other sub-functions. 

The “Form Tracks” sub-function uses contact reports from own-ship and external sources 
as an input. The controls for this sub-function are link settings and track files from the “Store 
and Report Tracks” sub-function. New track files and track file updates are outputs that are then 
used as inputs to the “Store and Report Tracks” sub-function. The use of both own-ship and 
external contact reports to form new track files and track file updates represents the EOR 
capability. 

The third and fourth sub-functions are “Classify Tracks” and “Identify Tracks,” 
respectively. The “Classify Tracks” sub-function does not have an input while the “Identify 
Tracks” sub-function uses intelligence data, query responses, and ship self-identification data 
from AIS as inputs. Both use track files and classification and identification criteria as controls 
and output track file updates. 

The fifth, sixth, and seventh sub-functions are “Correlate/Decorrelate Tracks,” “Associate 
Bearings/Fixes to Tracks,” and “Manage Track Numbers,” respectively. The 
“Correlate/Decorrelate Tracks” and “Manage Track Numbers” sub-functions do not have any 
inputs while the “Associate Bearings/Fixes to Tracks” sub-function uses EW bearings as an 
input. Each sub-function use link settings and track files as controls and outputs track file 
updates. 

The “Conduct Combat Control” function is decomposed into seven sub-functions as 
shown in Figure 27. These sub-functions include the following: Assess and Prioritize Threats, 
Determine Weapon Target pairing Options, Issue Engagement Order, Query Ship, Issue 
Boarding Order, Develop Execution Guidance, and Assess Engagement. 
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Figure 27: SV-4 A3 Diagram for Conduct Combat Control 

This figure is the decomposition of the Conduct Combat Control function. 


The first sub-function is “Assess and Prioritize Threats,” which does not have an input, 
but uses OPTASKs MIO SUPP and SUW, track files, and outputs from the “Develop Execution 
Guidance” sub-function, pre-planned responses, and weapons release criteria as controls. To 
support the DWC concept, the “Assess and Prioritize Threats” sub-function uses a threat 
evaluation algorithm that is common across the force. This sub-function outputs threat responses 
directly into the second sub-function “Determine Weapon Target Pairing Options.” 

The “Determine Weapon Target Pairing Options” sub-function uses the threat responses 
from the “Assess and Prioritize Threats” sub-function and weapon status as inputs. The controls, 
for this sub-function are airspace coordination order, friendly and neutral ship locations, pre¬ 
planned responses from the sixth sub-function “Develop Execution Guidance,” and OPTASKs 
MIO SUPP and SUW. The “Determine Weapon Target Pairing Options” sub-function supports 
the DWC concept by exporting own-ship engagement effectiveness estimates and by using both 
own-ship and external engagement effectiveness estimates as inputs to develop the weapon- 
target pairing options. This sub-function outputs weapon target pairing options directly into the 
third sub-function “Issue Engagement Order.” 

The “Issue Engagement Order” sub-function’s only input is the aforementioned weapon 
target pairing options. The controls for this sub-function are OPTASKs MIO SUPP and SUW 
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and pre-planned responses from the “Develop Execution Guidance” sub-function. In support of 
DWC, the “Issue Engagement Order” sub-function employs a weapon scheduling algorithm that 
is common across the force. This sub-function outputs a track file update and an order to fire. 

The fourth sub-function is “Query Ship,” which does not have an input, but uses 
OPTASK MIO SUPP, track files, and pre-planned responses from the “Develop Execution 
Guidance” sub-function as controls. This sub-function outputs a track file update and a query. 

The fifth sub-function is “Issue Boarding Order,” which does not have an input, but uses 
OPTASK MIO SUPP and track files as controls. This sub-function outputs a track file update, a 
query, and a boarding order. 

The sixth sub-function is “Develop Execution Guidance,” which uses environmental data 
as an input. The controls for this sub-function are OPTASKs LINK, MIO SUPP, and SUW. 
Outputs for this sub-function include: sensor plans, link settings, classification and identification 
criteria, boarding COMPLAN, pre-planned responses, and weapons release criteria. 

The seventh sub-function is “Assess Engagement,” which does not have an input and 
uses track files as a control. This sub-function outputs a track file update. 

After creating the OV-5 and SV-4 diagrams, the SV-5 was created to show the 
traceability between the operational activities and system functions as shown in Table 9. In an 
SV-5, only the leaf-level functions are mapped to their corresponding leaf-level operational 
activities. The top-level functions and operational activities are included in the diagram to help 
the reader trace the system function to operational activity mapping to the architecture diagrams. 
An ‘X’ placed in the matrix indicates that the system function implements that operational 
activity. All system functions map to at least one operational activity and vice versa. This 
ensures that all activities are supported by the system functions and that no system functions 
exists that do not support some operational activity. The verification of the enterprise 
architecture is discussed in Section IV.A “Modeling and Simulation”. 
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Table 9: SV-5 

The table indicates which system functions are used to satisfy the operational activities. 


Functions 

Operational Activities 

0 Perform Command and Control 

1 Collect Target Information 

1.1 Track Contacts 



2 Process Targets 

2.1 Request Attack 

2.2 Select Target to Attack 

2.3 Select Platform(s) and 

System(s) for Attack 

n 

2.5 Conduct Tactical Combat 
Assessment 

2.6 Select Ship To Visit, Board and 
Search 

3 Maintain Information and Naval 
Force Status 

3.1 Maintain and Display Tactical 
Picture 

3.2 Maintain and Display Force 
Command and Coordination Status 

3.3 Maintain and Display Unit 
Readiness 

0 Perform Command and Control 

















1 Display Tactical Data 

















1.1 Provide Tactical Display Configuration Options 














X 

X 

X 

1.2 Display Track Data 














X 



1.3 Display Engagement/VBSS Status 















X 


1.4 Display Sensor Status 
















X 

1.5 Display Command Data 















X 


2 Perform Track Management 

















2.1 Store and Report Tracks 



□ 











X 



2.2 Form Tracks 



□ 














2.3 Classify Tracks 




□ 













2.4 Identify Tracks 





□ 












2.5 Correlate/Decorrelate Tracks 



□ 














2.6 Associate Bearings/Fixes to Tracks 



□ 














2.7 Manage Track Numbers 



□ 














3 Conduct Combat Control 

















3.1 Assess and Prioritize Threats 

















3.1.1 Identify Threats 







□ 










3.1.2 Prioritize Threats 







□ 

□ 









3.1.3 Identify Actions Required for Each Threat 








□ 









3.2 Determine Weapon Target Pairing Options 

















3.2.1 Estimate Engagement Effectiveness 









X 








3.2.2 Identify Engagement Conflicts 









X 








3.2.3 Compile Weapon Target Pairing Options 









X 








3.3 Issue Engagement Order 










D 







3.4 Query Ship 





□ 












3.5 Issue Boarding Order 












X 





3.6 Develop Execution Guidance 

















3.6.1 Develop Engagement Guidance 
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3.6.2 Develop Sensor Plans 















X 


3.6.3 Develop Track Management Policy 















X 


3.7 Assess Engagement 











X 






4 Report Status 














X 

X 

X 


4. Conclusions 

The required behavior of the C2 system, which was based on the system’s requirements, 
was defined by the enterprise architecture. This enterprise architecture for the C2 system can 
effectively support both the SUW and MIO missions without the need for separate C2 system 
architectures. The operational activities that the systems support are defined by the OV-5 
diagrams. Then, the external system diagrams are used to show the external systems and entities 
that the system interfaces with to support the mission. Next, the C2 system’s functions are 
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defined by the SV-4 diagrams. Finally, the system’s functions are mapped to the operational 
activities via the SV-5. During the M&S task, which is described later in this report, COREsim 
and CPN validate the architecture to ensure that it is consistent and executable. 
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IV. MODELING AND ANALYSIS 


The Modeling and Analysis phase provides modeling and simulation results to verify the 
architecture, and cost analysis to identify and quantify potential cost savings as a result of 
adopting a common C2 architecture for Navy surface combatants. Similar to the previous phase, 
the requirements, architecture, mission threads, and threats were re-evaluated as appropriate and 
the stakeholders were contacted in order to ensure the project remained on task with the 
stakeholders’ needs (as verifying the architecture served as an integral part of the requirements 
and architecture development process). The Modeling and Analysis phase resulted in 
architecture verification and summarized analysis of the life-cycle cost savings from the 
consolidation of training modules. 

A. MODELING AND SIMULATION 

Two different, but complementary, M&S techniques were used to model the C2 system 
architecture: discrete-event simulation using COREsim, and state space analysis using Colored 
Petri Nets (CPN). The objectives for the verification effort were to detennine architecture 
completeness, to assess internal consistency within the architecture, and to verify that the 
architecture was executable. If not complete, consistent, and executable, then the M&S activities 
identify the specific deficiencies and adjustments needed to correct the architecture. COREsim 
supports architecture verification by demonstrating successful execution of an Enhanced 
Functional Flow Block Diagram (EFFBD) representation of the architecture through a finite 
number of simulation runs. CPN uses a state space analysis to identify logical issues that might 
not be uncovered in a fixed number of simulation runs. 

1. Architecture Verification using COREsim 
a. COREsim Background 

CORE is a model-based systems engineering (MBSE) tool with an integrated discrete event 
simulator called COREsim, which is used to create and execute a dynamic view of the 
architecture in order to verify logic, sequencing, and infonnation flows. COREsim uses the 
Enhanced Functional Flow Block Diagram (EFFBD) view of the architecture associated with 
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both the OV-5 and SV-4. The EFFBD, as a dynamic process-oriented view of the architecture, 
provides information about operational activities or system functions that are not captured by the 
other views, such as sequencing of events. The EFFBD also uses logic control constructs to 
specify the behavior of the system in response to stimuli (called triggers in CORE). Use of the 
simulator to step through the dynamic process model can reveal errors in the flow of information 
between activities or functions that are not apparent by looking at the IDEFO diagrams. 

The default EFFBD views, produced automatically within CORE for both the operational 
activities and the system functions, show all activities and functions in numeric sequential order 
along a single branch. To provide a more realistic view of the dynamic system, the model can be 
modified to include a variety of logic structures, such as parallel branches, “and/or” and 
“if/then/else” constructs, iterates, loops, and exits. CORE documentation [Vitech Corp, 2000] 
indicates that there are two ways to represent the concept of concurrency. The first is through 
the “iterate” construct, which allows for the processing of multiple tracks in sequence (not truly 
concurrent). The second is through the “replicate” construct, which allows for the processing of 
multiple tracks simultaneously from a single control function. However, since the “replicate” 
construct is not currently enabled in CORE, there is no explicit way to represent the parallel 
processing of multiple tracks or targets. Parallel branches can be used to represent the 
concurrent processing of activities or functions, but applies to only one target or track at a time. 

b. Verification Techniques 

COREsim was used to develop and execute the EFFBD views of both the operational 
activities and the system functions. Modifications were made to accommodate the differences 
between the IDEFO specification and the COREsim EFFBD modeling conventions in order to 
create an executable model. The default EFFBDs were not executable due to violations of 
COREsim rules. COREsim reads IDEFO controls as triggers in the EFFBDs, which is not 
desirable for items such as doctrinal or other guidance documents. A trigger in the EFFBD is 
used to initiate the execution of an activity or function. A control in IDEFO is used to represent 
information that guides or regulates how an activity is supposed to execute. 

COREsim also requires all triggers to come from activities or functions that are explicitly 
represented in the model. As an example, information from external sensor systems are 
represented as controls on the C2 system in the IDEFO diagrams, but are treated as triggers in the 
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EFFBD. These triggers were converted to inputs in order to allow the simulation to execute. 
Then the activity “New Track File Arrives” was added to the C2 operational activity EFFBD 
(Figure 28) to provide the initial triggering function as a proxy for the external sensor systems. 
The activity “Wait” was also added to the C2 operational activity EFFBD (Figure 28Figure 28: ) 
to control the time lapse between track arrivals. Similar changes were made to the C2 system 
function EFFBD (Figure 31). 

The conversion of external system IDEFO controls to EFFBD inputs and the addition of 
activities and functions to make the EFFBD executable substantively changed the IDEFO 
representation of the architecture. Thus, it was necessary to maintain two versions of the CORE 
model; the original with properly described IDEFO diagrams and a simulation version with 
COREsim executable EFFBDs. 

In addition to the adjustments required to allow the EFFBDs to execute in COREsim, 
adjustments were made to the sequencing of activities and functions to more closely reflect 
reality. Parallel processing was used to reflect concurrency of the operational activities and 
system functions, where applicable. Triggers were used to control sequencing of events between 
parallel branches. The “iterate” function was employed to allow for sequential processing of 
multiple tracks in a single run of the simulator. Figure 28 shows the top-level C2 operational 
activities, arranged in parallel, with iterations (labeled as “IT” in the diagram) to allow 
representation of multiple successive tracks. 
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Figure 28: EFFBD of Top-Level C2 Operational Activities 


This EFFBD displays the top-level operational activities executed in parallel, with iteration to 
support successive multiple targets within a single run of the simulation. 




The input and output information flows have been suppressed in the figures to make the 
diagrams easier to read, but all are included and used in the simulation. Triggers are shown in 
ovals with double-headed arrows. All of the sub-model EFFBD for operational activities were 
created and are available in Appendix D. The second-tier of the operational activity model for 
the “Process Targets” activity is shown in Figure 29. In this particular implementation of the 
model, a 100% probability is assigned to the upper branch in order to test only the ability to 
process the SUW related activities. The MIO mission is represented by the activity on the lower 
branch. To toggle between the mission threads, the branch probabilities can be assigned as 
100% and 0% or vice versa. It is also possible to assign other combinations of probabilities to 
each branch (such as 50% and 50%), and to have both types of missions occur within a single 
run of the simulator. Variations were tested to ensure that the model executes as expected. 
There are numerous alternative ways that this could have been modeled, including multi-exit 
functions that select the appropriate branch using control logic and exceptions logic that bypass 
both of those options. For modelers with coding skills, the CORE scripting language could also 
be used to add more fidelity to the model. 
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Figure 29: Target Processing C2 Operational Activities 


This EFFBD is the decomposition of the “Process Targets” Operational Activity. The top branch 
includes activities associated with the SUW mission. The bottom branch shows the activity 
associated with MIO. 


Figure 30 is a graphical representation of the COREsim output of a single simulation run. In 
this simulation run, the C2 operational activities process three track files, which represent targets, 
arriving in succession. The existence of a graphical representation of the simulation run indicates 
that the simulation executes with no technical errors. 
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This figure shows the COREsim model results for three targets arriving in succession. Each track 
is processed and there are no errors in the model. 

The operational activity names are listed in the column on the left. The corresponding 
rectangles on the right side of the diagram indicate blocks of time allotted to each activity. Dark 
green blocks correspond with activities that have no trigger, while the light green indicates that 
the activity was triggered by outputs from another activity. The yellow indicates a period of time 
that the activity is actively waiting to be triggered. The boxes with hatching marks represent the 
rolled up higher-level activities. The decomposition is not shown for those activities that are 
both continuous and concurrent in order to focus attention on the sequential activities as they 
apply to each track. 

Timing can be independently specified for each activity or function as a constant value, a 
probability distribution (a variety of distributions are available) or in accordance with a CORE 
script. For this project, the COREsim model was used to verify the structure of the architecture, 
not to validate the time-based performance measures as developed in the value system design. 
As a consequence, the time values used were not relevant to the objectives of the assessment and 
set solely to improve the readability of the diagram. 

The corresponding EFFBDs and results from COREsim are shown for the SV-4 diagrams 
in Figure 31, Figure 32 and Figure 33. Figure 31 shows the top-level C2 system functions 
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arranged in parallel with a single “iterate” construct to allow for multiple successive targets. All 
of the sub-model EFFBD for system functions were created and are available in Appendix D. 



Figure 31: EFFBD of Top-Level C2 System Functions 

This figure shows the top-level system functions as an EFFBD, where each function is executed in 
parallel to support multiple targets. 


Figure 32 is focused on the second-tier of “Conduct Combat Control,” where the 
SUW mission is represented by the upper branch and assigned a probability of 100%, while the 
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MIO mission is represented by the lower branch and assigned a probability of 0% (for this 
specific simulation run). 



Figure 32: Conduct Combat Control C2 Functions 

This figure shows the child functions of the Conduct Combat Control function. The separate 
branches show the functions associated with the SUW and MIO missions. 


Results of a simulation run using just the SUW mission thread are shown in Figure 33. The 
graphic shows the relative sequencing and concurrency of the “Conduct Combat Control” C2 
functions. The model runs without error. The continuous functions, “Display Tactical Data” and 
“Perform Track Management,” have been collapsed to focus on the details of the sequential 
processing of each target in “Conduct Combat Control.” As with the operational activities 
model, the timing for each function could be adjusted and defined as either a constant, a 
probability distribution, or in accordance with a script. In this model, the only adjustment made 
to the default timing was to extend the “Wait” time so that it is easier to make the visual linkage 
between the “Conduct Combat Control” functions and the associated track file in the top line. 

As with the operational activities, there is no basis for making changes to the default constant 
value, as there is no objective to validate the time-based system performance requirements at this 
stage. 
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Figure 33: COREsim Results from C2 System Functions 


The figure shows the result of three targets arriving in succession. No errors were found during 
execution. 


c. Results 

Within the limited scope of the COREsim assessment, no logical flaws in the architecture 
were identified. The EFFBDs could be enhanced, adding control functions to more explicitly 
portray decision points, but these were not absolutely necessary to verify the architecture. There 
was value in the EFFBDs, which provided additional information about the sequencing of the 
activities and functions. The process of developing the EFFBD views provided greater 
understanding of the architecture. 

The full functionality of COREsim was not explored; but the timing capabilities could 
possibly be used in the context of the larger weapon system, supporting tradeoff decisions 
between C2 and engagement system time allocations and using the threat assessment results to 
bound the problem space. The results of timing studies could assist in identification of the 
specific physical implementation of the system. Also not used was the resource constraint 
capability in COREsim. This is also useful when evaluating engagement systems, as there are 
always constraints on resources such as ammunition. The constraint requirements developed for 
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this project were enterprise-level constraints that were not directly applicable to the C2 system 
modeling of a specific tactical engagement. 

CORESim requires the use of parallel branching, iterations, loops and triggers to 
approximate the concurrency inherent in the IDEFO diagrams. Due to the complexity of these 
changes, the CORESim assessment was focused on a small segment of the architecture. To fill in 
these gaps, and more thoroughly assess the logical consistency of the architecture, CPN 
modeling was used. 

2. Architecture Verification Using Colored Petri Nets 
a. Colored Petri Net Background 

The CPN language was developed specifically for the purpose of modeling and 
verification of concurrent, distributed systems. A CPN model represents the states of a system 
and the events that may cause the system to change state [Jensen, 2009]. Due to the way CPNs 
are specified, models can be simulated or assessed logically through a state space analysis. 

The CPN modeling language consists of three elements: places, transitions, and arcs. 
Places represent data that is available within the system and is specified by a color, better known 
as a data type. Transitions are processes that take data from places, convert that data and send 
output data to other places. Transitions are specified by a guard condition that limits data that 
can be accepted by the transition and by the transition’s code segment, which defines how input 
data is processed. Arcs define the paths, from places to transitions and transitions to places, 
which the data may follow [Jensen, 2009]. To provide a parallel to the SV-4 System 
Functionality Description in DoDAF, a transition is equivalent to a system function while an arc- 
place-arc combination is equivalent to a data flow (an example is shown in Figure 34). 
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Two other concepts are important to understanding how the CPN language works. The 
first is the notion of a token. During the execution of a CPN model, a token represents the actual 
instantiation of a data element in the model. For example, a token in the C2 system architecture 
would be an instantiation of a track file during execution. A marking is simply the set of tokens 
at all of the places in the CPN model at a point in time during the model’s execution. A marking 
defines the state of the CPN model [Jensen, 2009]. 

CPN Tools was used to develop the CPN model and to conduct all of the verification 
activities. CPN Tools is a freely available tool developed by the University of Aarhus in 
Denmark. CPN Tools has an intuitive Graphical User Interface and allows for specification of 
guard constraints and code segments using the CPN Markup Language, which is based on 
Standard Markup Language [Jensen, 2009]. 
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b. Modeling Assumptions 

Several assumptions on the scope of the verification effort were made. Of highest 
importance, only the functional architecture (SV-4) was verified. Due to the mapping of the SV- 
4 System Functionality Description to the OV-5 Operational Activity Model, in the SV-5, no 
significant benefit would be achieved from a separate verification of the activity model. 

The verification effort included only the target processing components. As a 
consequence, planning and display functions were not included in the verification. This includes 
the functions “1 Display Tactical Data”, “3.6 Develop Execution Guidance”, and their 
descendents. The rationale for this scoping decision was to exclude functions that provided a 
persistent input to the track processing functions, namely the planning functions, or did not have 
a feedback into the track processing functionality, specifically the display functions. 

Similarly, external entities were modeled only if the architecture included a direct output- 
input relationship with the external entity that affected target processing. For practical purposes, 
this limited the external entities that were included to commercial ships, which receive queries 
from the C2 system and return a query response. 

In order to keep the verification effort to a manageable size while still being able to 
assess the key elements of the architecture, verification was done using two concurrent targets, 
one commercial and one non-commercial. This allowed the verification effort to assess the 
proper concurrent execution of the SUW and MIO missions and to assess how well the 
architecture handles multiple, simultaneous targets. 

The SV-4 was represented exactly as it appears in the architecture with only a single 
exception. The “Store and Report Tracks” function was implemented as a persistent data store in 
the CPN model. In the architecture, the “Store and Report Tracks” function serves the larger 
purpose of reporting track data to external command entities. However, as described above, that 
portion of the function is not within the scope of the verification, only the data store component 
remained. Figure 35 shows how the “Store and Report Tracks” function is implemented in the 
System Functionality Description and how it is implemented in the CPN model. 
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Figure 35: Depiction of "Store and Report Tracks" function in SV-4 and 
CPN models 

The figure shows how the “Store and Report Tracks” function is implemented in the SV-4 as a 
function and as a place in the CPN model. In the CPN model, the “Store and Report Tracks” 
function is replaced by a “Track Files” place that serves as a track data store for other functions. 

c. Verification Techniques 

Two separate approaches were used during the verification of the architecture. First, 
simulation of the CPN model was used to initially assess whether the architecture executed 
properly. This technique used a step-by-step evaluation of the CPN model’s execution to ensure 
that the commercial and non-commercial threats were handled properly and that the model 
consistently terminated with both targets processed. The CPN approach has the unique 
advantage over the use of COREsim in that the architecture can be assessed in its IDEFO form 
and does not need to be converted into an EFFBD to support simulation. 

The second verification approach was a state space analysis. The advantage of a state 
space analysis over a simpler simulation-based assessment is that the state space analysis checks 
all possible states that the model may assume. This gives the state space analysis the ability to 
identify logical flaws that may not manifest themselves during the execution of a finite number 
of simulation runs. 
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The state space analysis employs several distinct checks. The full state space, consisting 
of all possible markings of the system, is calculated. Based on the state space, three assessments 
are made: the Strongly Connected Components (SCC) graph is calculated, the home and dead 
markings are detennined and any live or dead transitions are recorded. Each assessment is 
discussed in more detail below. 

Two markings are in the SCC-graph if and only if they are mutually reachable. This 
means that a finite occurrence sequence exists between the markings. A SCC-graph that is 
smaller than the full State Space indicates the presence of cycles (infinite occurrence sequences) 
in the model [Jensen, 2009]. An infinite occurrence sequence in the model implies that it is 
possible that the model will never “finish” or reach a marking where there are no enabled 
transitions. If the architecture is correctly designed, the SCC-graph will be the same as the full 
State Space. Figure 36 gives an example of a SCC-Graph that is not the full state space. 



Figure 36: Example of SCC-graph that is a subset of the state space 

Note that the markings in the SCC-graph cannot be reached from the markings outside the SCC- 
graph. If the markings outside the SCC-graph are reached, the model will never “finish”. 

The home markings and dead markings provide valuable information about the states in 
which the architecture has terminated. The home markings can be reached from any marking, 
meaning that from any possible marking of the system, the home marking can be subsequently 
reached. For our architecture, the marking where all targets have been processed should be 
reachable from any other marking and thus should be a home marking. The dead markings are 
states where no transition is enabled [Jensen, 2009]. This equates to the states where the 
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architecture has “finished”. If the architecture is correctly defined, the only dead markings 
should be the marking where all targets have been processed. 

Finally, the live and dead transitions provide some additional information about the 
model. A live transition is any transition where an occurrence sequence exists from every 
reachable marking that contains the transition. Note that a live transition cannot exist if a dead 
marking exists. A dead transition is a transition where no reachable markings exist where the 
transition is enabled [Jensen, 2009]. Essentially, the transition can never execute. For a 
correctly defined architecture, neither live nor dead transitions should exist. 

d. Results 

During the simulation verification, ten runs were observed in step-wise execution without 
observed error. All runs tenninated in the marking with all targets processed. The state space 
analysis also verified the architecture’s logical structure. The SCC-graph showed that the model 
has no infinite occurrence sequences. Additionally, the home marking and dead markings were 
identified and both correspond to the state with all targets processed. This means that the state 
with all targets processed is the only state reachable from all reachable markings and is the only 
state where no transitions are enabled (where the model is “finished”). 

Since the state with all targets processed was identified as the sole dead marking, no live 
transitions exist. As well, no dead transitions were identified. Thus, there are no functions in the 
architecture that can never be executed. 

In conclusion, the CPN verification results confirm that the architecture is logically 
complete and internally consistent. The architecture, as it is defined, has no infinite loops that 
prevent the successful processing of targets and will tenninate only in the state where all targets 
have been processed. 


B. COST ANALYSIS 
1. Background 

As previously discussed, and will be shown below, the architecture provided inputs to the 
basis of the cost analysis task. The Cost Analysis task was conducted in parallel with the M&S 
task under the assumption that the tasks were independent of each other. The Cost Analysis task 
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determined that in today’s surface fleet, each major C2 system has its own unique training 
pipeline and capability upgrade activities that are part of the life cycle costs. Though they may 
have common missions, the C2 system functions, modes, and operator displays are different, 
requiring distinct training activities for each system. To field a capability upgrade across C2 
systems, the upgrade is developed and tested for each C2 system, incurring costs for essentially 
the same work multiple times. Using a common C2 architecture across multiple platforms has 
the potential of avoiding the distinct training activity costs and repetitive costs for upgrade 
development. Cost analysis was conducted to test the surface navy acquisition community’s 
assumption that a common C2 architecture and set of requirements would lead to systems that 
are less costly in terms of operator training and system capability upgrades and to quantity the 
potential savings. 

2. Methodology 

a. Historical Cost Data 

Initially, much effort was expended trying to obtain actual dollar cost values from DoD 
finance sources such as the Defense Cost and Resource Center maintained by the Office of the 
Secretary of Defense, the Navy Visibility and Management of Operating and Support Costs 
(VAMOSC) database, and Navy Budget Reports from the Assistant Secretary of the Navy’s 
Financial Management and Comptroller site. However, these sources generally do not provide 
cost information decomposed to the C2 system level. For instance, the Defense Cost and 
Resource Center production costs are provided at the ship level. VAMOSC lists annual training 
costs for both Aegis and SSDS, but the costs are not decomposed to the specific C2 subsystem 
level. Navy Budget Reports list FY08 costs for specific capability upgrades for both Aegis and 
SSDS, but none are purely C2 upgrades. Without historical cost data at the C2 level, a 
meaningful parametric cost estimation relationship cannot be derived [Anderson, 2008]. 

b. Training Hours 

Due to the lack of useable detailed data produced from this initial effort, the focus of the 
cost analysis was shifted to obtaining Aegis and SSDS training hours for the specific warfare 
area functions defined in the common C2 architecture. Hours spent training were used as a cost 
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metric instead of dollars. Aegis and SSDS C2 subsystem training hours were obtained from the 
Center for Surface Combat Systems (CSCS), which serves as the training site for both Aegis and 
SSDS operators [Parker and Salunga, 2009]. These metrics were traced directly back to the 
common C2 architecture by identifying the specific training courses and hours that cover the 
specific mission area C2 functions. Surface Warfare functions covered in both Aegis and SSDS 
curriculums of instructions were candidates for cost avoidance. The Navy could potentially 
condense these courses, thereby reducing the number of courses required, the number of 
instructors hours required, and the amount of training material preparation needed, resulting in 
more affordable training. 

The seven-week Aegis Combat System Officer Track II course and the seven-week SSDS 
Combat System Officer course contain the majority of the surface warfare area mission training 
requirements [Parker and Salunga, 2009]. Curricula of instruction were obtained for both 
training courses from CSCS [Aegis Training and Readiness Center, 2009]. Aegis and SSDS 
subject matter experts provided assistance with course content where the Navy currently teaches 
subjects related to the surface warfare mission area functionality identified in the project 
architecture. The CSCS then provided calendars for each course that indicated the number of 
instruction hours planned per curriculum item. The number of instruction hours for the portions 
of the curriculum of interest was extracted from the calendars. Table 10 shows the results of the 
analysis. The columns indicate the functions of the C2 architecture created in this report and the 
rows identify the curriculum items. The intersecting cells indicate the number of hours of 
instruction for each function of the architecture. Curriculum items not related to surface warfare 
or the C2 architecture were not included in this analysis. An empty cell indicates no training of 
this function occurs in this curriculum item. The training hours extracted from the calendars for 
each curriculum item are shown in the far right hand column. The hours were distributed evenly 
to the relevant intersecting cells as an estimate of the instruction hours per function. Total 
instruction hours per C2 function were calculated for each course. The bottom row shows the 
smaller of the Aegis and SSDS training hours per function and represents the potential training 
hours that could be saved if these C2 systems had a common architecture for surface warfare 
mission functions. 
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Table 10: C2 Training Hours 

This table shows the C2 training hours from the Aegis and SSDS Combat Systems Officer courses allocated to the common architecture 
functions. The hours per function are totaled and co mpar ed to deter mine potential duplicative training hours 
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c. Capability Upgrades 


System complexity was investigated as a comparative measure of cost for a C2 system 
capability upgrade. System interface information could be used to determine the complexity of a 
system. As an indicator for system complexity, the number of interfaces a system has, or the 
number of message types a system passes across an interface, could provide quantitative values 
to compare across different systems. In theory, the more complex the system, the more costly it 
would be to update [Tumey, 2000]. 

This type of information could be used to assess the level of complexity of a system. 
With access to system interface documents, interface variables such as quantity of interfaces and 
quantity of message types across each interface could be used as values to compare the relative 
complexity between multiple systems. A thorough, quantitative analysis of this kind of 
information requires access to some classified sources for a complete definition of all interfaces. 
In order to keep the report unclassified, the complexity versus upgrade cost aspect was not 
pursued.. 


3. Cost Analysis Conclusions 

Table 10 shows a total of fifty-nine training hours from both the Aegis and SSDS 
curriculum that could potentially be condensed if a common C2 system for surface warfare was 
used. Fifty-nine hours is 25% of the total (including non C2) instructional hours from each 
course. From a future C2 system perspective, this is a potential cost avoidance of fifty-nine 
training hours in the surface warfare mission alone by using a common C2 system across 
platforms. 

Note this data shows no common hours for the MIO unique functions Query Ship and 
Issue Boarding Order. MIO is not part of the Aegis Combat System Officer course, nor is MIO 
part of the Aegis curriculum at CSCS [Parker and Salunga, 2009]. One recommendation for 
further study (using the same training hour metric) would be to explore other warfare areas 
including MIO. It is also quite possible that additional surface warfare training hours would be 
considered common. This analysis only considered one course for each C2 system that the 
CSCS staff considered to contain the majority of C2 training. Broadening this approach to other 
mission areas could support the general notion that a mission driven system functional 
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architecture will result in functionality across systems that would be similar as to ease the 
training requirements across systems. 

This cost analysis supports the surface navy acquisition community’s assumption that a 
common C2 system will reduce the cost of training. However, due to the lack of open source 
information on Aegis and SSDS C2 interfaces and message types, a conclusion on the 
assumption that common C2 would reduce the cost of capability upgrades could not be reached. 
A second recommendation for further study is to examine the availability of the interface 
information and the validity of using interface complexity as a cost metric. 
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V. SUMMARY AND AREAS FOR FURTHER STUDY 


A. SUMMARY 

The objective of this report was to test the assertion that a common architecture would 
reduce combat system lifecycle costs. The project used a three phase Systems Engineering 
model (Figure 37) to gather stakeholder inputs, develop a common architecture, and then 
investigate if the common architecture can support training cost savings. The products from 
each successive phase served as inputs for the follow-on phases. 

Through this process, a common architecture for a generic naval warship C2 system was 
developed, using two mission threads, SUW and MIO, as a basis for the functionality of the 
system. The system functionality identified in the architecture was used to identify course 
material from two current combat systems that could be combined if a combat system was 
developed using a common architecture. The cost analysis findings indicate that potential 
savings in training hours could be realized if a common architecture were to be developed. 

There were three steps in the Needs Analysis Phase: Stakeholder Analysis proved to be 
the foundational step in clarifying the problem statement. Primarily through review of joint and 
naval service doctrine, this step revealed a conceptual functionality of the purpose of a C2 
system and desired characteristics of a C2 system. Another important concept gained during this 
step was that a C2 system includes software, hardware, and people. This concept was a key 
contributor leading into the mission thread development. The stakeholder interviews conducted 
during this step validated some of the infonnation gathered in the document review, giving the 
analysis a “real person” perspective. 

The purpose of the threat assessment was to gain an understanding of the types of vessels, 
and their threat characteristics, that the C2 system might encounter. Extensive open source 
research was conducted in this area and the results of the research contributed to C2 
requirements development and analysis. The threat assessment could also be valuable in 
defining sensor characteristics such as range, search rate, and resolution. However sensor 
systems and specific timing requirements were beyond the scope of the project. 
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Figure 37: Summary of Project Systems Engineering Process 


This Figure summarizes the three phase systems engineering process used to develop the 
enterprise architecture and to estimate potential cost savings achieved by using a common 
architecture. Outputs from each phase provided inputs to follow-on phases. 


Like the Stakeholder Analysis, the Mission Thread definition also provided foundational 
information for the project. Two mission threads built upon the information gathered in the 
Stakeholder Analysis. This step translated the high level concepts into a more detailed level of 
activities and interactions, which were then used to support requirements and architecture 
development. Another key aspect of this step was problem scoping. The mission threads 
delineated what was inside the system boundaries, and what was outside the system boundaries. 
For example, sensor characteristics were outside of the system boundary, as discussed above. 
People, on the other hand, as it was learned during the Stakeholder analysis, were inside the 
system boundary. 
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The next phase, Functional Analysis, included three steps: Requirements Definition, 
Value System Design, and Enterprise Architecture. The Requirements Definition produced 
written statements to describe the characteristics of the C2 system. This step was the li nk 
between the concepts in the Needs Analysis and the system functionality depicted in the 
architecture. This step provided the quality control that the functions in the architecture correctly 
supported the concepts of the Needs Analysis phase. Through traceability from the Needs 
Analysis concepts to the functions documented in the architecture, the requirements definition 
step ensured that the needs analysis concepts were being addressed and also that the architecture 
did not include unnecessary functions. 

The Value System Design identified quantitative values or ranges that were included as 
attributes of the requirements. These values would be useful during design and development 
when the systems are actually being built; defining how well the systems need to perform. The 
values also provide a benchmark during testing, as a measure of how well the system performs. 
However, the contributions of the Value System Design step was negligible for the scope of this 
project, which was the high level definition of requirements and architecture to support training 
cost evaluation. 

The Enterprise Architecture step described the functionality and interactions of the C2 
system, working within the boundaries established by the mission threads and the requirements. 
The architecture further described the functionality of the system, and also how the functions 
would interact with each other. A key objective of this step was to describe the functionality of 
the system. This system functionality was then used in the development of the end state of this 
project - the training cost analysis. 

The final phase of the project was Modeling and Analysis. This phase included two 
unrelated steps, validation of the architecture and cost analysis. Since both steps involve 
modeling and analysis, they were included in the same phase. However, there is risk that the 
independent steps are misinterpreted as being dependent upon each other. The purpose of the 
Modeling and Simulation step was to validate that the functions in the architecture were 
organized in a logical and executable manner; for example an architecture that classifies a 
contact before it detects it would not be realistic or executable. The model and simulation step 
validated that the organization of the functional architecture was reasonable. 
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The Cost Analysis step provided the end product for this project - an assessment of 
whether an enterprise architecture could result in training cost savings. The step used a matrix to 
compare the functions in the project architecture to known topics being taught in current, 
independent C2 system courses. The unions between functions and course topics identified 
potential areas of overlap for the two training courses evaluated. The project used course hours 
as the comparison metric. Actual dollar cost was considered as a metric option but rejected 
because of the greater amount of variability associated with training costs. Training hours was 
considered to be a more metric for comparison. The analysis concludes that the design of a 
common C2 system, derived from an enterprise C2 architecture could support training cost 
savings. 

Overall, the project team learned that it is possible to design a functional architecture 
based upon some high-level concepts and needs. It is critically important to conduct research in 
order to understand stakeholder needs. Written requirements add clarity and definition to the 
initial problem concept. Architecture products add fidelity and increase the understanding of the 
initial need. The systems engineering process used in this project does help move the Navy 
towards an enterprise architecture approach to achieve cost savings. 

B. AREAS FOR FURTHER STUDY 

This report acknowledges the limited scope of this project. Areas for further study were 
identified throughout the development of this study and are summarized below. 

• Further mature the requirements and architecture developed in this report: 
Using the process identified in this report, work could be continued to add to the 
fidelity of the existing requirements and architecture set. Additional requirements 
and architecture products could be developed. Quantitative values could be refined 
and added to the requirements. These same quantitative values could then be 
incorporated into the architecture and perfonnance tested. 

• Expand the architecture to additional mission areas: Additional mission threads 
could be developed (for example, conduct air warfare). Associated requirements and 
architecture products could then be developed and added to these existing products. 

• Conduct additional cost analysis: Cost analysis in the training area could be 
expanded in several ways, including: investigation of additional training methods, 
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adding actual cost values to the existing metrics identified in this report, and 
investigating training hours for additional mission areas. Other areas for further study 
include the investigation of additional cost metrics, maintainer documents, spare 
parts, logistics infrastructure and capability upgrade comparisons. 
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APPENDIX A: PROGRAM MANAGEMENT PLAN 


INTRODUCTION 

This is the project management plan (PMP) for the Naval Postgraduate School (NPS) Masters of 
Science in Systems Engineering (MSSE) program capstone project Cohort 311-074. The PMP 
was prepared by the Naval Surface Warfare Center (NSWC) Corona Division and Dahlgren 
Division team. The project is an enterprise requirements and architecture (ER&A) initiative. 

Problem Statement 

Across the Surface Navy Enterprise, each new ship class implements a new command and 
control (C2) design for the combat system with a unique set of system requirements and 
associated architecture. This leads to individual platform development efforts, operations and 
support requirements, and training pipelines which complicates interoperability and incurs 
additional costs to the Navy. There is a need to define a superset of requirements and a common 
enterprise command and control architecture that can be implemented by multiple surface ship 
platforms. A single architecture, defining the functionality required and allocating those 
functions to system elements, would allow for a concept of modular sensor and weapon interface 
elements. If the architecture is reusable and scalable to future ship classes, a potential for 
lifecycle cost savings exists. 

Project Proposal 

Surface combatant platforms commonly have battlespace awareness as well as command and 
control (C2) for core ship self-defense and area-defense missions in the area of surface warfare 
(SUW). The NSWC team will use Department of Defense Architecture Framework (DoDAF) 
products to define an enterprise-level C2 architecture that is independent of existing systems or 
platforms. The architecture developed will support functionality normally performed by guided 
missile cruisers (CG), guided missile destroyers (DDG), and guided missile frigates (FFG), with 
the expectation that the concepts and processes developed in this project can be scaled to broader 
surface platform applications. The DoDAF products will be based upon two representative 
mission threads and associated C2 functionality. 


103 



The NSWC team has identified two mission threads to be assessed, one of a combat nature and 
one of a non-combat nature: 

• Conduct SUW - Detect, track, identify, report, support engagement decisions, and 
maintain status on surface contacts. 

• Conduct maritime interception operations (MIO) - Exchange information during a MIO 
event to support battlespace awareness and decision-making. 

The above mission threads will be addressed in the architecture and developed to exercise the 
following C2 functionality [DoDCCRP, 2008]: 

• Common Tactical Picture (CTP) 

o The capability for all participating units to display the same tactical picture as the unit 
that detects the target. 

o The ability to accurately report contact identification, heading, position, and speed. 

• Common Operational Picture (COP) 

o The ability to follow a set doctrine that is common among all units. 

o The ability to accurately report ship and strike group status to higher-level command 
organizations and to receive and maintain force-level status. 

• Tactical C2 

o The ability to follow the Navy or Joint Task List for the following critical operational 
components: detect, track, identify, report, engage, and manage data. 
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Risk Management 

The Project Management team will be responsible for risk analysis, risk mitigation and risk 
tracking. Project members will contribute to risk identification. Risk analysis will follow a 
standard likelihood and consequence assessment and use the risk rating matrix in the Risk 
Management Guide for DoD Acquisition. Due to the constraints of the academic calendar and 
the absence of funding for the effort, all risks are to perfonnance. In other words, the quality of 
the product is what is at risk, not when it will be delivered or at what cost. 

Limited options exist for risk mitigation within the structure of the Capstone project, therefore, 
avoidance of risk may require a renegotiation of the PMP. Control of risk by adding personnel 
or maintaining parallel approaches will be severely constrained by the extent of existing tasking. 
There is no external entity onto which to transfer risk. This makes risk assumption the default 
mitigation approach. If risks are realized such that the NSWC team will not be able to satisfy the 
PMP, the risk will be mitigated via a renegotiation of the PMP with a reduced scope in the risk 
area. 


Risk status will be reported by the Program Management team at each Integrated Product 
Review (IPR). If required, risks will be reported in the interim periods to the advisors and 
project stakeholders by the Program Management team. The two major, initial risks have been 
identified and assessed, summarized in Table 1. 


Table 1: Risk Management Matrix 


Risk 

ID 

Risk 

Name 

Description 

Likelihood 

Consequence 

Risk 

Rating 

R001 

Cost 

Analysis 

Data 

Not all data required to 
complete the cost analysis 
may be available. 

Near 

Certainty 

(5) 

Minor (2) 

Y ellow 

R002 

M&S 

Data 

Not all data required to 
complete the performance 
analysis may be available. 

Highly 

Likely (4) 

Moderate (3) 

Y ellow 


105 






















Vision 

The NSWC team’s vision is to create an enterprise-level C2 architecture for CGs, DDGs, and 
FFGs, with the expectation that the architecture can be generalized and utilized by other 
platforms. The core architecture addresses two diverse mission threads, a combative and non- 
combative thread. This combination of threads will allow the team to work through and identify 
several of the issues that may not be realized through an otherwise similar mission thread 
selection. Ultimately, the enterprise solution developed will act as a foundation for future Navy 
application. This foundation will be used to save the Navy integration lead time, minimize 
redundant logistic support pipelines, and reduce the need for stovepipe training methods. 
Further, this architecture will lead to a cross-trained sailor and a more effective and unified Fleet. 

End-State 

The NSWC team will develop a superset of C2 requirements for multiple platfonns based on the 
mission threads to conduct SUW and MIO. The team will develop an enterprise-level C2 
architecture and will provide DoDAF products based on the mission threads and the superset of 
C2 requirements. The NSWC team will perform a cost analysis to establish potential cost 
differences with current configurations of C2 architecture. The final report will document the 
methodology and the process used to identify the superset of requirements, providing a traceable 
and repeatable means for developing other C2 architectures for differing mission threads. 

PROJECT PARTICIPANTS 
Team Members 

The ER&A capstone project team is composed of sixteen students enrolled in the MSSE with a 
systems development focus distance learning program at NPS in Monterey, California. The team 
members and their respective organizations are listed in Table 2. 
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Table 2: NSWC MSSE Team Members 


NSWC DAHLGREN 

NSWC CORONA 

Joanna Beger-Mason 

Elvis Acosta 

Harry Donovan 

Jordan Barta 

Matt Eak 

Llewelynn Galace 

Dave Finley 

Andrina Maurseth 

Brian Jones 

Lee Metz 

Lesley Painchaud 

Reshma Suchit 

Josh Pepper 


Rob Tidwell 


David Yu 


Bob Zanella 



Team Organization 

The NSWC project team is organized into four working groups (WG) as shown in Figure 1. 
Each working group will manage specific roles and responsibilities, which will be discussed in 
detail in subsequent sections. As a collective, the working groups collaborate to form the NSWC 
integrated product team (IPT) to deliver the final project report and presentation. 



Figure 1: NSWC IPT Structure 


Roles and Responsibilities 

The ER&A effort will be integrated organizationally to accommodate the assigned technical 
authorities and engineering specialties commensurate with the requirements of the project. The 
NSWC team has identified key working groups in an effort to assign points of contact and 
accountability for all major tasks. Working group personnel and responsibilities are addressed in 
the subsequent section. Figure 2 identifies the leads and members of the working groups. 
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Figure 2: NSWC Working Group Structure 


Project Management Working Group 

The Project Management group coordinates the overall activities of the NSWC project team. 

The project management working group consists of the Project Leaders, Technical Assistants 

(TAs) Schedulers, and Librarians. 

• Project Leader 

The project leader is responsible for overall management of the capstone project. There is a 
leader at each NSWC site (Dahlgren and Corona) to manage and execute the project 
according to the project plan and to maintain a balance between the technical, schedule, and 
administrative requirements of the project and organization of working groups. The project 
leader responsibilities include: facilitate group meetings and infonnation exchange, monitor 
and guide the overall project activities, foster team member participation, and promote 
collaboration among the working groups. 
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• Librarian 


The Librarian is responsible for cataloguing reference material, tracking and verifying 
sources of research, and ensuring completeness of references for project deliverables. The 
Librarian will coordinate Blackboard document control efforts with the working group 
leaders. 

• Schedulers/Technical Assistants (TA) 

Schedulers/TAs are responsible for assisting the project lead with administrative tasks, 
recording and distributing meeting minutes, scheduling either ElluminateLive! or Defense 
Connect Online (DCO) sessions, maintaining the master schedule and plan of action and 
milestones (POA&M), and creating Blackboard repositories for the team's various 
documents. 

Editorial Working Group 

The purpose for this working group is to ensure that all deliverable documents comply with the 
SE Writing Standards and to ensure that the documents are comprehensive and complete. The 
editorial WG consists of an editor-in-chief, report editors, and presentation editors. 

• Editor-in-Chief 

The primary responsibility of the editor-in-chief is to review and edit all deliverable 
documentation. The editor-in-chief delegates responsibilities to the other members of the 
editing staff as necessary. The editor-in-chief will also work with the Librarian to ensure that 
all sources have been cited appropriately. 

• Report Editor 

The report editors will assist the editor-in-chief with the reviewing and editing of report 
sections, ensuring that the content is consistent with the presentation material, and ensuring 
content meets SE Writing Standards and milestone requirements. 
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• Presentation Editor 


The presentation editors will assist the Editor-in-chief in reviewing and editing of 
presentations, ensuring that the content is consistent with the report material, and ensuring 
the content meets SE Writing Standards, milestone requirements, and Integrated Product 
Review (IPR) requirements. 

Requirements Analysis Working Group 

The requirements analysis working group coordinates the efforts of the following working 
groups: stakeholder analysis, mission thread development, threat assessment, requirements 
definition, and value system design. Each of these working groups will aid in the formulation of 
a comprehensive set of requirements. 

• Stakeholder Analysis Working Group 

The stakeholder analysis working group is responsible for identifying clients (and 
organizations) that will benefit in the success of the ER&A being developed. Analysis 
includes identifying the client’s needs and objectives, which will be used to translate into 
functional requirements. The lead will maintain contact with the stakeholder(s) and will 
coordinate with the advisors to solicit information. 

• Mission Threads Working Group 

The mission threads working group is responsible for researching and establishing the 
mission threads that are required for ER&A. 

• Threat Assessment Working Group 

The threat assessment working group is responsible for conducting an analysis of threats to 
naval platforms relevant to the selected mission threads. 

• Requirements Definition Working Group 

The requirements definition working group is responsible for translating stakeholder needs 
and objectives into ER&A functional requirements and tracing these requirements to the 
applicable system elements. 
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• Value System Design Working Group 

The value system design working group is responsible for creating a value tree (a composite 
of the stakeholder and functional analyses) and identifying metrics, such as perfonnance 
measures. The lead will coordinate with the stakeholder analysis and requirements definition 
working groups to ensure the model reflects the stakeholders’ needs and objectives and 
functional requirements and will provide the metrics to the Modeling & Simulation (M&S) 
working group. 

Architecture Working Group 

The architecture working group is responsible for overseeing and coordinating the development 
of the architecture for the enterprise requirements. This group will participate in preparation of a 
high-level system and requirements definition and coordinate with the project leads and modelers 
on execution of all technical aspects of the architecture. The architecture group will also prepare 
and submit an ER&A integration report to the project leads, which will identity interfaces 
between systems, subsystems, and platforms that need to be included as part of ER&A. 

• Modeling & Simulation Working Group 

The modeling and simulation working group will identify M&S tools and assist other 
working groups in developing and conducting M&S to evaluate the effectiveness of the 
combat system command and control architecture. 

• Cost Estimation Working Group 

The cost estimation working group will ensure that all cost categories are considered and that 
a cost-benefit analysis is completed for decisions in the program. The cost analysis includes 
the evaluation of trade-offs that reduce cost while still meeting all operational requirements. 

Advisors 

The ER&A capstone project lead advisors are Mr. Gregory Miller and Prof. Paul Montgomery, 
faculty members of the Department of Systems Engineering at NPS. The ER&A capstone 
project support advisor is Dr. Emmett Maddry, a senior leader at NSWC Dahlgren Division. 
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Stakeholders 

The roles of the stakeholders will be to evaluate the merit of the project and provide direction to 
help guide the development efforts. The primary activities of the stakeholders will be to provide 
informal feedback to the students throughout the project and provide fonnal feedback by 
participating in the three project reviews. If conflicting guidance or objectives are received from 
stakeholders, the team will negotiate with the stakeholders to attempt to achieve a consensus. 
Given the limited performance period of this project, the team (with staff advisor concurrence) 
will choose a solution to implement for the project and document the discrepancy of non¬ 
concurrence in the final report. At this time the NSWC team is still in the process of identifying 
stakeholders and thus far, three stakeholders at NSWC Dahlgren have been identified, Mr. Gil 
Goddin, Mr. Tim Neel, and Mr. Doug Haas. 

Mr. Gil Goddin is a Senior Systems Engineer in the Warfare Systems Department Warfare 
Systems Engineering and Analysis Division. He is the Warfare Systems Definition Branch head 
and is currently the enterprise Systems Engineer who works with Program Executive Office 
(PEO) Integrated Warfare Systems (IWS) to define commonality across platforms for combat 
system design. 

Mr. Tim Neel is a Senior Combat Control Systems Engineer in the Warfare Systems Department 
Combat Control Division. Mr. Neel has extensive experience leading C2 and combat system 
architecture development efforts. He is currently involved in three distinct C2 and architecture 
efforts. 

Mr. Doug Haas serves as the Senior Technical Advisor to the Warfare Systems Department 
Combat Control Division and supports the department for combat control systems engineering 
matters regarding the continued advanced development of surface combatants. He has a broad 
working knowledge of the architecture, requirements, performance, capability and limitations of 
the individual combat control systems providing this functionality. 

The NSWC team has identified three other potential stakeholders at NSWC Dahlgren; however 
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the team has not yet confirmed that these stakeholders will be able to participate. The team will 
also attempt to identify and engage user and resource sponsor stakeholders. 

MANAGEMENT PROCESS 

Systems Engineering Design Process (SEDP) 

The NSWC team will employ a tailored systems engineering design process (SEDP) illustrated 
in Figure 3 to establish a C2 enterprise architecture and requirements. This process is an 
adaptation of the systems engineering process published in System Engineering Fundamentals 
from the Defense Acquisition University in January of 2001 was tailored to reflect the actual 
phases planned for this Capstone Project. 

The process begins with the Needs Analysis phase, where the problem statement is refined to 
understand the stakeholders and their actual needs and expectations. This phase will also 
describe the mission threads that the team identified as part of the project proposal and identify 
the threat against which the C2 architecture and requirements must perfonn. These tasks will 
occur in parallel. 

The Functional Analysis phase will define the system-level requirements, followed by a 
functional architecture for the C2 aspects of the platform and a value system design by which the 
architecture will be evaluated. As the team works through this phase, the team will return to the 
tasks performed in the Needs Analysis phase to determine whether stakeholder input is needed 
for clarification, whether threads are adequately defined, or whether threats are fully established. 

The Modeling and Analysis phase will provide simulation results to support and further define 
the metrics identified during the Functional Analysis phase. The team will also perfonn a cost 
analysis to identity potential cost differences in current configurations. Similar to the previous 
phase, the team will re-evaluate the requirements, architecture, mission threads, and threats as 
appropriate and will contact the stakeholders to detennine whether the project remains on task 
with the stakeholders’ needs. This project will result in a documented process for developing a 
scalable enterprise requirements and architecture set, as well as specific requirements and 
architecture sets to support the identified project mission threads. The following sections specify 
the tasks, input and output, and tools required for the NSWC team to perform the defined tasks. 
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Figure 3: NSWC Tailored Waterfall Process 

Needs Analysis Phase 

• Task 1 Stakeholder Analysis 

This task will identify the applicable stakeholders, identify key stakeholder guidance, and 
identify the guiding principles for further needs analysis. Stakeholder guidance includes 
strategy documents, doctrinal publications, tactical publications, and tactical task lists. 

Inputs: Problem statements 

Tools: Publication review, interviews with stakeholders 

Outputs: Description of stakeholder needs and guidance, desired measures to be 

used in Value System Design phase 
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• Task 2 Mission Thread Definition 


This task will research and establish the mission threads that are required for ER&A. This 
task will define the details of the SUW and MIO mission threads. 

Inputs: Problem statements, stakeholder analysis, Navy doctrine and publications, 

mission thread identification 

Tools: Affinity diagrams, research, mission threads, context level extended 

functional flow block diagrams (EFFBDs) 

Outputs: Mission thread definition, context diagram 

• Task 3 Threat Assessment 

This task will identify the potential threats to U.S. Navy platforms during the conduct of 
SUW and MIO missions across the spectrum of operating areas and conventional and non- 
conventional threat systems. 

Inputs: Problem statement, stakeholder analysis, mission thread definition 

Tools: Research 

Outputs: Threat assessment 

Functional Analysis Phase 

• Task 1 Requirements Definition 

This task will translate stakeholder needs and objectives into ER&A functional requirements 
and decompose these requirements into a functional architecture. 

Inputs: Stakeholder analysis, mission thread definition, threat assessment, context 

diagram 

Tools: CORE 

Outputs: Initial requirements hierarchy, functional hierarchy, operational activity 

diagram (OV-5), enterprise requirements, requirements traceability 

• Task 2 Enterprise Architecture 

This task will produce the enterprise architecture for the combat system. 

Inputs: Enterprise requirements 

Tools: CORE 

Outputs: Enterprise architecture 

• Task 3 Value System Design 
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This task will produce a value tree, which decomposes the architecture down to applicable 
functional levels. This task will identify metrics, such as perfonnance measures. 

Inputs: Enterprise requirements and architecture 

Tools: CORE 

Outputs: Metrics and threshold values 

Modeling and Analysis Phase 

• Task 1 Modeling and Simulation 

This task will produce models to simulate the architecture requirements and to validate the 
architecture developed in the previous phases. This task will also provide input to the cost 
analysis. 

Inputs: Value system design, enterprise architecture and requirements 

Tools: CORE, Arena, Microsoft Excel 

Outputs: Simulation output and description 

• Task 2 Cost Analysis 

This task will explore life cycle costs associated with common ship C2 (combat) enterprise 
requirements across platforms. 

Inputs: Historical cost data, enterprise architecture and requirements 

Tools: Microsoft Excel, Visibility and Management of Operating and Support 

Costs (VAMOSC) database 
Outputs: Cost analysis 

SCHEDULE & DELIVERABLES 
Schedule 

The schedule developed for the ER&A project is shown in Figure 4. The period of perfonnance 
is defined as September 2008 through June 2009. The schedule is driven by the milestones 
identified below: 

• Approval of PMP 

• Integrated Product Reviews (#1, #2, final brief out) 

• Completion of the Systems Engineering Design Process phases 
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Deliverables 

The following deliverables have been identified for advisor and stakeholder concurrence: 

• November 2008: PMP 

• December 2008: IPR 1 Presentation, Report Draft Release #1 which will focus on: 

• Program Management Plan 

• Needs Analysis Overview 

• Stakeholder Analysis 

• Mission Thread Definition 

• Threat Assessment 

• Risk Management Update 

• The Way Forward 

• March 2009: IPR 2 Presentation, Report Draft Release #2 which will focus on: 

• Updates from IPR #1 

• Functional Analysis Overview 

• Requirements Definition 

• Functional Architecture Status 

• Value System Design 

• Risk Management Update 

• The Way Forward 

• June 2009: Final Presentation; Final Report 

• Updates from IPR #2 

• Final Functional Analysis 

• Modeling and Simulation Overview 

• Modeling and Simulation Results 

• Cost Analysis 

• Risk Management Update 

Each IPR will include three basic sections. A progress update will focus on the work and 
products that been completed. A risk management update will focus on the risks identified and 
mitigation strategies developed for medium to high risks. The third section of each IPR will 
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include a way forward, in which the team schedule for the future will be reviewed. In these IPRs 
the team will elicit feedback from the stakeholders and advisors. Any comments provided will 
be addressed prior to the final presentation. 
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ID 

Task Name 

1 

Enterprise Requirements/Architecture 

2 

Needs Analysis 

3 

Program Management Plan (PMP) 

4 

PMP Development 

5 

Final PMP (Approved) 

6 

Stakeholder Analysis 

7 

Mission Thread Definition 

8 

Threat Assessment 

9 

IPR #1 

10 

Functional Analysis 

11 

Requirements Definition 

12 

Enterprise Architecture 

13 

Value System Hierarchy 

14 

IPR #2 

15 

Modeling and Simulation 

16 

Modeling & Simulation 

17 

Cost Analysis 

18 

Final Brief Out 

19 

Reporting 

20 

Report Development 

21 

Draft Release #1 

22 

Draft Release #2 

23 

Final Report 


| October | November | December | January February 


21 28 5 12 19 26 2 9 16 23 30 7 14 21 28 4 11 18 25 1 8 15 22 


March April May | Ju ne 

19 26 3jl0 17 24 31] 7 114 
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Figure 4: Schedule 
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PMP: Appendix A: Acronym List 


Acronym 

AV 

C2 

C4I 

CG 

COP 

CTP 

DCO 

DDG 

DoDCCRP 

DoDAF 

ER&A 

EFFBD 

FFG 

IPR 

IPT 

IWS 

M&S 

MIO 

MSSE 

NPS 

NSWC 

ov 

PEO 

PMP 

POA&M 

SE 

SEDP 

SI 

SUW 

TA 

VAMOSC 


Term 

All View 

Command and Control 

Command, Control, Communications, Computers, Intelligence 

Guided Missile Cruiser 

Common Operational Picture 

Common Tactical Picture 

Defense Connect Online 

Guided Missile Destroyer 

Department of Defense Command and Control Research Program 

Department of Defense Architecture Framework 

Enterprise Requirements and Architecture 

Extended Functional Flow Block Diagram 

Guided Missile Frigate 

Integrated Product Review 

Integrated Product Team 

Integrated Warfare Systems 

Modeling & Simulation 

Maritime Interception Operations 

Masters of Science in Systems Engineering 

Naval Postgraduate School 

Naval Surface Warfare Center 

Operational View 

Program Executive Office 

Project Management Plan 

Plan of Action & Milestones 

Systems Engineering 

Systems Engineering Design Process 

System Integration 

Surface Warfare 

Technical Assistant 

Visibility and Management of Operating and Support Cost 


121 



THIS PAGE INTENTIONALLY LEFT BLANK 


122 



APPENDIX B: STAKEHOLDER INTERVIEW QUESTIONS 


1. What are the future trends in Surface Warfare and Maritime Interdiction Operations that will 
drive ship combat system requirements? 

a. Technical 
e.g. OA, SOA 

b. Operational 

e.g. Distributed operations 

2. What are the major current and emerging surface threats to U.S. Navy platforms that the ship 
combat system must address? 

e.g. Cyber attacks, piracy, semi-submersible or other low-observable surface vessels, 
FAC/swarm attacks, suicide attack by unmarked (civilian) vessels 

3. Limited to the Surface Warfare and Maritime Interception Operations, what major 
requirements can you identify for the ship’s combat system? 

a. Relative to functionality the ship combat system must support? 

b. Relative to the perfonnance or operational availability of the system? 

c. Relative to specific requirements for system (ship and coalition) redundancy? 

d. Relative to the current & future interfaces the ship combat system must support? 

e. Relative to the operational environment that the ship combat system must operate in? 

4. What are the performance and/or RMA criteria that define the “goodness” of the ship combat 
system? 

5. What perfonnance aspects of the ship combat systems are most important? Which are least 
important? 

6. Are there any constraints on the combat system that we need to include in our requirements 
analysis? 

7. Are there any cost or schedule constraints that we need to be aware of? 

e.g. Weapon system must be ready for certain test events X months prior to full ship test events. 

8. How does the trend toward net-centricity & reliance upon coordinated tracks, cooperative 
fires, etc. impact combat system command and control functionality and performance? 
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9. Does the trend toward net-centricity & reliance upon coordinated tracks, cooperative fires, 
etc. drive navigation accuracy or track measurement report precision, gridlock precision, track 
update rates, or other performance metrics? 

10. What do you expect as the final product of this effort? Do you expect a section of a formal 
requirements document or a product that would be expanded by a follow-on effort? 

11. Do you have any additional comments or recommendations? Do you know of any other 
stakeholders we could speak with from the resource sponsor (OPNAV) or fleet (CFFC)? 
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APPENDIX C: C2 REQUIREMENTS, VSD & ARCHITECTURE MATRIX 


In Table 11 each requirement is listed in the “Requirements” column and is tracked by 
number in a hierarchical arrangement in which higher level requirements are decomposed into 
multiple lower level requirements, as indicated by the number of decimal points in the requirement 
number. (Requirement 1.2 decomposed into 1.2.1, 1.2.2, etc.) The “Rationale” column contains 
the source information for that requirement, and may be attributed to a Joint or Navy publication, a 
stakeholder, the mission threads, or another doctrinal source. In the case where the rationale refers 
to an NTA, definition can be found in the Navy Tactical Task List. Requirements that do not 
reference an external source were derived as necessary to ‘fill in’ the architecture when required. 
The “Type” column indicates whether a requirement is a functional or perfonnance requirement, 
or a constraint. Functional requirements describe what the system must be able to do. 
Performance requirements describe how well the system must perform. Constraint requirements 
describe other operational or design limitations with which the system must comply. The “Value 
System Design” column further describes the requirement in terms of the intended objective and 
Performance Measures. The “Architecture Function” column contains the architecture function to 
which the requirement has been allocated. Only the lowest leaf levels in the requirements 
hierarchy have been allocated to functions. A “leaf’ is the lowest decomposition of a requirement 
in the hierarchy. The leaf level requirements and associated functions support the higher level, or 
parent, requirement. 
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Table 11: Complete C2 Requirements and VSD 

This table contains a complete listing of all System Requirements and the Value System Design. 


Requirement 

Rationale 

Type 

Value System Design 

Architecture Function 

1 Command and Control 

The system shall support Command 
and Control activities. 


Functional 



1.1 Conduct Maritime Interception 
The C2 system shall support 
maritime interception operations. 

NT A 1.4.6 

Functional 

Obj: Assess if visit and boarding 
were successful. 

PERFORMANCE MEASURE: 
Ability of C2 system to support 
visit and board contact. 

Goal: 99% of all MIO Missions 
conducted successfully 


1.1.1 Conduct Visit 

The C2 system shall provide the 
capability for ship personnel to 
request a vessel to heave to, for 
purposes of conducting a visit. 

NT A 1.4.6.1 

Functional 

Obj: Assess if boarding party and 

C2 can successfully inspect and 
examine a vessel. 

PERFORMANCE MEASURE: 
Ability of C2 to facilitate 
conducting a visit on a vessel. 

Goal: 99% of all MIO visits 
successful 
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Requirement 

Rationale 

Type 

1.1.1.1 Query 

The system shall support the 
querying of vessels and the 
transmissions of notifications to 
conduct VBSS operations. 


Functional 

1.1.1.2 Request to Board 

The C2 system shall provide the 
capability for ship personnel to 
request a vessel to heave to, for 
purposes of conducting a visit. 

NT A 1.4.6.1 

Functional 


1.1.2 Conduct Search 

The C2 system shall support vessel 

searches. 


NT A 1.4.6.2 


Functional 


Value System Design _ 

Obj: Assess if ship personnel can 
successfully query a vessel. 


Architecture Function 

3.4 Query Ship 


PERFORMANCE MEASURE: 

Ability of C2 to facilitate query of 
a vessel. 

Goal: 99% of all MIO queries 

successful _ 

Obj: Assess if the request to board 3.5 Issue Boarding Order 
is communicated. 

PERFORMANCE MEASURE: 

Ability of C2 to effectively 
communicate a request to board 
transmission. 

Goal: 99% of all MIO 
transmissions and receipt of all 

boarding message are successful. _ 

Obj: Assess if C2 effectively starts 3.5 Issue Boarding Order 
a search plan. 

PERFORMANCE MEASURE: 

Ability of C2 system to find 
contact and evaluate the 
compliance of the vessel under 
evaluation. 


Goal: Probability of detection of a 
contact during sensor scans > 99% 






















Requirement 

Rationale 

1.1.3 Conduct Seizure 

The C2 system shall support the 
capability to identify any violation of 
resolutions or sanctions. 

NT A 1.4.6.3 

1.1.3.1 Take Possession of Vessel 
Upon identification of a resolution or 
sanction violation, the C2 system 
shall support the action of taking 
legal possession of the vessel. 

NT A 1.4.6.3 

1.1.3.2 Take Possession of 
Contraband 

Upon identification of a resolution or 
sanction violation, the C2 system 
shall support the action of taking 
legal possession of the contraband, to 
include goods and people. 

NT A 1.4.6.3 


Type 

Functional 


Functional 


Functional 


Value System Design _ Architecture Function 

Obj: Assess if C2 system I 

effectively supports personnel in 
seizure of a vessel. 

PERFORMANCE MEASURE: 

Capability of C2 system to identify 
vessels in violation of resolutions 
and/or sanctions. 

Goal: Probability of correct ID of a 

contact > 99% _ 

Obj: Assess if C2 correctly IDs that 3.5 Issue Boarding Order 
vessel is in possession 

PERFORMANCE MEASURE: 

Capability of C2 to correctly 
Identify vessels in possession 

Goal: Probability of correct ID of a 

vessel in violation >99% _ 

Obj: Assess if C2 correctly IDs 3.5 Issue Boarding Order 

vessels contents 

PERFORMANCE MEASURE: 

Capability of C2 to correctly 
Identify a vessel’s contents 

Goal: Probability of correct ID of 
contents of a suspected vessel 
>99% 























Requirement 

Rationale 

Type 

1.1.4 Maritime Interception 

USN/USCG 

Functional 

Operations (MIO) Reporting 

The C2 system shall support the 
automated reporting of query and 
boarding status and Situation Reports 
(SITREP). 

2003 


1.1.4.1 Maintain Status 

Stakeholder 

Functional 

The C2 system shall maintain a query 
and boarding status for each MIO 
action. 

Analysis 



1.1.4.2 Provide Reports 

The C2 system shall provide surface 

situation reports. 


Stakeholder 

Analysis 


Functional 


Value System Design _ Architecture Function 

Obj: Assess if C2 reports 
information regarding queries and 
boarding activity 

PERFORMANCE MEASURE: 

Capability of C2 to report out 
information regarding MIO 
activities. 

Goal: Probability of correctly 
reporting of query/boarding status 

>99% _ 

Obj: Asses C2 functionality in 3.4 Query Ship 
maintaining status on all boarding 3.5 Issue Boarding Order 
and query activities 

PERFORMANCE MEASURE: 

Measure C2 capability in 
maintaining a database of all 
boarding and query activities 

Goal: C2 shall keep an active li nk 

on status of boarding party > 99% _ 

Obj: Assess C2 ability in producing 4 Report Status 
reports 

PERFORMANCE MEASURE: 

Measure C2 effectiveness in 
producing reports 

Goal: Meantime for C2 to provide 

reports to CO < 5 mins. _ 






















Requirement 

Rationale 

Type 

Value System Design 

Architecture Function 

1.1.5 Classify and Identify Surface 
Contacts 

The C2 system shall utilize stored 
intelligence data to classify and 
identify surface contacts. 

USN/USCG 

2003 

Functional 

Obj: Determine C2 classification 
completeness and accuracy 

PERFORMANCE MEASURE: 
Ability to classify as friend, foe, 
suspect, or assumed friend based 
on database information 

Goal: Accuracy and completeness 
of surface contacts >95% 

2.3 Classify Tracks 

2.4 Identify Tracks 

1.2 Collect Target Information 

The C2 system shall collect target 
information for detecting, identifying, 
locating, and classifying targets. 

NTA 2.2.1 

Functional 

Obj: Determine C2 capability of 
sensors to identify an object under 
varied noise, weather, terrain 
conditions 

PERFORMANCE MEASURE: 
Ability of sensors to identify an 
object under varied noise, weather, 
terrain conditions 

Goal: Probability of detection and 
classification of a target >99% 
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Requirement _ Rationale 

1.2.1 Receive Sensor Inputs Goddin, 

The C2 system shall utilize radar, 2008; Haas & 

electro-optical/infrared (EO/IR), Neel, 2008 

electronic surveillance (ES), 

identification friend-or-foe (IFF) and 

automatic identification system (AIS) 

data in the classification and 

identification of contacts. 


1.2.1.1 Sensor Data 

The track file shall include radar, 

EO/IR, ES, acoustic, IFF and AIS 

data. _ 

1.2.1.2 Correlate Sensor Data 

The C2 system shall correlate radar, 

EO/IR, ES, acoustic, IFF and AIS 

data into a single track file. _ 

1.2.2 Classify Surface Contacts NTA2.2.1.3 
The C2 system shall classify surface 

contacts. 


Type 

Functional 


Functional 


Functional 


Functional 


Architecture Function 


Value System Design _ 

Obj: Assess C2 functionality in 
receiving data from sensors in 
detection, ID, and classification of 
contacts. 

PERFORMANCE MEASURE: 

Ability of C2 to correctly and 
accurately detect, Identify, classify 
contacts from sensor data 

Goal: Probability of correct 
detection, ID, and classification 
from all sensor systems >85% 

2.1 Store and Report 

(same as 1.2.1) Tracks 

2.5 Correlate/Decorrelate 

(same as 1.2.1) Tracks 

2.6 Associate 

_ Bearings/Fixes to Tracks 

Obj: Detennine C2 ability to assess 
contact classification completeness 
and accuracy 

PERFORMANCE MEASURE: 

Ability of C2 to accurately and 
completely classify all contacts. 


Goal: Probability of correct 
classification and accuracy of 
surface contacts >99% 

























Requirement _ Rationale Type _ Value System Design _ Architecture Function 

1.2.2.1 Classification Types NWP 3-20 Functional Obj: Determine if C2 can 2.3 Classify Tracks 

Classification types shall include: appropriately classify vessels by 

combatant, type or category (combatant, non¬ 
noncombatant military, combatant military, merchant, 

merchant, fishing, etc), 

fishing, 

pleasure. PERFORMANCE MEASURE: 

Ability of C2 to classify by type of 
vessel 

Goal: Probability of correct 
classification of vessel 

_ type/category >99% _ 

1.2.2.2 Sensor Inputs Functional Obj: Assess C2 functionality in 2.3 Classify Tracks 

The C2 system shall use inputs from using data from organic and 

organic and national asset sensors to national asset sensors to classify 

classify contacts. contacts. 

PERFORMANCE MEASURE: 

Ability of C2 to effectively use 
inputs from organic and national 
asset sensors to classify contacts. 

Goal: Probability of correct 
classification based on asset 

_ sensors >85% _ 

1.2.2.3 Classification Completeness NTA Perfonnance 2.3 Classify Tracks 

The C2 system shall assign a 2.2.1.3.M1 

classification to TBD % of detected 
surface contacts. 
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Requirement _ Rationale 

1.2.2.4 Classification Accuracy 
The C2 system shall assign a correct 
classification to TBD % of classified 

surface contacts. _ 

1.2.2.5 Classification Timeliness NTA 

The C2 system shall correctly 2.2.1.3.M3 

classify TBD % of detected contacts 

within TBD minutes. _ 

1.2.3 Identify Contacts JP 1-02, NTA 

The C2 system shall identify contacts 2.2.1.4 
as friendly or hostile. 


1.2.3.1 Identification Completeness NTA 

The C2 system shall assign an 2.2.1.4.M3 

identity to TBD % of classified 

surface contacts. _ 

1.2.3.2 Identification Accuracy 
The C2 system shall assign the 
correct identity to TBD % of 

identified surface contacts. _ 

1.2.3.3 Identification Timeliness NTA 

The C2 system shall correctly 2.2.1.4.M1 

identify TBD % of classified contacts 
as friendly or hostile within TBD 
minutes. 


Type 

Value System Design 

Architecture Function 

Perfonnance 


2.3 Classify Tracks 

Perfonnance 


2.3 Classify Tracks 

Functional 

Obj: Determine C2 ability to ID 
contacts 

PERFORMANCE MEASURE: 
Ability of C2 to correctly and 
accurately ID contacts 

Goal: Probability of correct and 
accurate ID of contacts during 
active scanning >99% 


Perfonnance 


2.4 Identify Tracks 

Perfonnance 


2.4 Identify Tracks 

Perfonnance 


2.4 Identify Tracks 
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Requirement _ 

1.2.3.4 Automated Identification 
The system shall use range ring, 
radar, EO/IR, ES, acoustic, IFF and 
AIS data to identify targets. _ 

1.2.3.4.1 Kinematic Information 
The C2 system shall use kinetic 
information to identify targets. 

1.2.3.4.2 Muzzle Flash 

The C2 system shall use muzzle 
flashes to identify targets. 


Rationale 

Haas & Neel 
2008 


Haas & Neel 
2008 


Haas & Neel 
2008 


1.2.4 Focalize Contacts 
The C2 system shall localize the 
position of surface contacts. 


NTA2.2.1.5 


1.2.4.1 Track & Status Reporting 
The C2 system shall report track data 
for all surface contacts and own ship 
status data via Fi nk -16 and GCCS-M. 


Type 

Functional 


Functional 


Functional 


Functional 


Functional 


Value System Design _ 

Same as sensor requirements 
/PMs/Goals 


Architecture Function 






Same as sensor requirements 
/PMs/Goals 

2.4 Identify Tracks 


Same as sensor requirements 
/PMs/Goals 

2.4 Identify Tracks 


Obj: Assess if C2 can create tracks 
from multiple sources of data and 
communication networks of 
detected contacts 

PERFORMANCE MEASURE: 
Ability of C2 to create local and 
composite tracks of contacts 
detected 

Goal: Probability of creating 
correct and accurate tracks of 
surface contacts >85% 



Same as 1.2.4 objectives and 
performance measures 

2.1 Store and Report 

Tracks 
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Requirement 

Rationale 

Type 

Value System Design 

Architecture Function 

1.2.4.2 Sensor Netting and 

Distributed Weapons Control 

The C2 system shall be able to 
exchange contact data with other 
platforms to form local tracks. 

Haas & Neel 
2008 

Functional 

Same as 1.2.4 objectives and 
performance measures 


1.2.4.2.1 Engagement 

The C2 system shall be able to 
engage targets using contact data 
from other platforms. 

Haas & Neel 
2008 

Functional 

Obj: Determine C2 ability to issue 
engagement orders from contact 
data. 

PERFORMANCE MEASURE: 
Capability of C2 to issue 
engagement orders from contact 
data 

Goal: Mean time in issuing 
engagement order <30 seconds 

2.2 Form Tracks 
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Requirement 

Rationale 

Type 

Value System Design 

Architecture Function 

1.2.4.2.2 Sensor Netting 

The C2 system shall be able to send 
contact reports to, and receive contact 
reports from, other platforms, using 
contact data from other platforms to 
form tracks with own ship contact 
reports. 


Functional 

Obj: Assess C2 ability to 
participate in a sensor/net centricity 
environment 

PERFORMANCE MEASURE: 
Capability of C2 to send and 
receive contact reports. 

Capability of C2 to use contact data 
from other platforms to form tracks 
with own ship contact reports. 

Goals: 

Probability of successful 
transmission and receipt of contact 
reports > 95% 

Probability of successful 
integration of other platfonn 
contact data > 95% 

2.2 Form Tracks 

1.2.5 MIO Intelligence 

The C2 system shall utilize available 
intelligence data to classify and 
identify surface contacts 


Functional 

Obj: Determine C2 ability in 
utilizing available database 
intelligence to classify and ID 
contacts 

PERFORMANCE MEASURE: 
Ability of C2 to correctly and 
accurately classify and ID contacts 

Goal: Probability of correct and 
accurate classification and ID 
>99% 
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Requirement 

Rationale 

Type 

Value System Design 

Architecture Function 

1.2.5.1 Automatic Identification 
System 

The C2 system shall use commercial 
vessel intelligence data to support the 
classification and identification of 
surface contacts. 

USCG 2008 

Lunctional 

Same as 1.2.5 objectives and 
Perfonnance measures 

2.4 Identify Tracks 

1.2.5.2 National Asset Intelligence 
The C2 system shall receive, parse 
and store intelligence data from 
National Intelligence Assets, 
including National Maritime 
Intelligence Center (Merchant Ship 
Characteristics & Hidden 
Compartment Book) and Sealink 
Database of Vessels (ELINT 
parameters of known vessels). 

USN/USCG 
2003; MIO 
thread 

Lunctional 

Same as 1.2.5 objectives and 
Perfonnance measures 

2.4 Identify Tracks 

1.2.6 Link Planning 

The system shall be able to receive, 
parse and apply the OPT ASK LINK 

derived 

Lunctional 


3.6.3 Develop Track 
Management Policy 
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Requirement 


1.3 Process Targets 

The C2 system shall process surface 

targets to employ response systems. 


Rationale 


NTA3.1 


Type 





1.3.1 Pre-planned Responses (PPR) 
The C2 system shall be able to 
receive, parse and implement PPRs. 


1.3.2 Request Attack 

The C2 system shall be able to order 

an attack on a specific target or 

position. 


1.3.2.1 Request Timeliness 
The C2 system shall submit TBD% 
of all attack requests within TBD 
minutes. 


CNO 2007 Functional 


NTA 3.1.1 


NT A 
3.1.1.M2 


Functional 


Value System Design 


Obj: Assess C2 capability to 
correctly and accurately ID/classify 
contacts and make command and 
decision (C&D) in contact 
processing and action to contacts 

PERFORMANCE MEASURE: 
Evaluate C2 ability to process ID 
and classification of contacts in 
making C&D actions. 

Goal: Probability of correct action 
based on ID and classification 
>99.9% 


Same as 1.3 objectives and 
Perfonnance measures 


Same as 1.3 objectives and 
Perfonnance measures 


Architecture Function 


Perfonnance Obj: To submit attack requests in a 
timely manner. 

PERFORMANCE MEASURE: 
Timeliness of attack requests 



3.6.1 Develop 
Engagement Guidance 



Goal: The C2 system shall submit 3.3 Iss 
TBD% of all attack requests within Order 
TBD minutes. 


3.2.1 Estimate 
Engagement Effectiveness 

3.2.2 Identify Engagement 
Conflicts 

3.2.3 Compile Weapon 
Target Pairing Options 

3.3 Issue Engagement 
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Requirement 

Rationale 

Type 

1.3.3 Select Surface Target to Attack 
The C2 system shall select the 
surface target to attack. 

NTA 3.1.2 

Functional 

1.3.3.1 Define Target Selection 
Criteria 

The C2 system shall allow for 
definition of target selection criteria 
for attack. 

NTA 3.1.2 

Functional 

1.3.3.2 Weapon Intercept Points 

The C2 system shall detennine 
weapon intercept points. 

NTA 3.1.2 

Functional 

1.3.3.2.1 Correlate Target Reports 

The C2 system shall correlate target 
reports into a track list and maintain 
the target list. 

NTA 3.1.2 

Functional 

1.3.3.2.2 Update Intercept Points 

The C2 system shall update weapon 
intercept points. 

NTA 3.1.2 

Functional 

1.3.3.2.3 Duplicate Tracks 

The C2 system shall avoid duplicate 
track files for single objects. 

NTA 3.1.2 

Functional 


Value System Design 

Same as 1.3 objectives and 
Perfonnance measures 


Architecture Function 




Same as 1.3 objectives and 
Perfonnance measures 

3.1.1 Identify Threats 

3.1.2 Prioritize Threats 

3.2.1 Estimate 

Engagement Effectiveness 

3.2.2 Identify Engagement 
Conflicts 

3.2.3 Compile Weapon 
Target Pairing Options 

Same as 1.3 objectives and 
Perfonnance measures 


Same as 1.3 objectives and 
Perfonnance measures 

2.5 Correlate/Decorrelate 
Tracks 

Same as 1.3 objectives and 
Perfonnance measures 

3.1.3 Identify Actions 
Required for Each Threat 

3.2.1 Estimate 

Engagement Effectiveness 

3.2.2 Identify Engagement 
Conflicts 

3.2.3 Compile Weapon 
Target Pairing Options 

Same as 1.3 objectives and 
Perfonnance measures 

2.5 Correlate/Decorrelate 
Tracks 




































Requirement _ 

1.3.3.3 Examine Target 
The C2 system shall examine each 
target to detennine if and by what 
time to issue an attack order. 


1.3.3.3.1 Target Evaluation 
Percentage 

The C2 system shall evaluate TBD% 
of all targets identified for attack. 

1.3.3.3.2 Evaluation Timeliness 
The C2 system shall complete target 
selection within TBD minutes after 
the contact has been localized or 
identified (whichever is greater). 

1.3.3.4 Maintain Target List 

The C2 system shall maintain the 
target list. _ 

1.3.3.5 Track Data Comparison 
The C2 system shall allow for 
comparison of target track data to 
selection criteria. 

1.3.3.6 Warning Orders 

The C2 system shall be able to issue 
warning orders to targets selected for 
attack. 


Rationale 

NTA 3.1.2 


NT A 
3.1.2.Ml 


NTA 
3.1.2.M3 


NTA 3.1.2 


NTA 3.1.2 


Type 

Value System Design 

Architecture Function 

Functional 

Same as 1.3 objectives and 
Perfonnance measures 

2.4 Identify Tracks 

2.5 Correlate/Decorrelate 
Tracks 

2.6 Associate 
Bearings/Fixes to Tracks 

3.1.1 Identify Threats 

3.1.2 Prioritize Threats 

3.1.3 Identify Actions 
Required for Each Threat 

Perfonnance 


3.1.1 Identify Threats 

3.1.2 Prioritize Threats 

3.1.3 Identify Actions 
Required for Each Threat 

Perfonnance 


3.2.1 Estimate 

Engagement Effectiveness 

3.2.2 Identify Engagement 
Conflicts 

3.2.3 Compile Weapon 
Target Pairing Options 

Functional 

Same as 1.3 objectives and 
Perfonnance measures 

2.7 Manage Track 

Numbers 

Functional 

Same as 1.3 objectives and 
Perfonnance measures 

2.5 Correlate/Decorrelate 
Tracks 

3.1.2 Prioritize Threats 

3.1.3 Identify Actions 
Required for Each Threat 

Functional 

Same as 1.3 objectives and 
Perfonnance measures 

3.1.3 Identify Actions 
Required for Each Threat 
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Requirement _ Rationale 

1.3.4 Select Platform(s) and NTA 3.1.3 

System(s) for Attack 

The C2 system shall detennine best 

weapon system, based on availability, 

intercept time, intercept point, and 

probability of negation, to employ 

against a particular target. 


1.3.4.1 Process Weapon System NTA 3.1.3 
Status 

The C2 system shall process status 
information from the engaging 
weapon system. 


Type 

Functional 


Functional 


Value System Design _ Architecture Function 

Obj: To determine capability of C2 
to select best weapon system for 
target 

PERFORMANCE MEASURE: 

Mean time for selected weapon 
system to engage target. 

Accuracy of target impact. 

Goals: 

Missile: Time < 5 minutes , 

Accuracy of engagement > 99% 

Small Boat: Time less than X 
minutes, Accuracy > 99% 

Ship: Time less than 5 minutes, 

Accuracy >99% _ 

Obj: To determine capability of C2 3.2.1 Estimate 

to process weapon status Engagement Effectiveness 

information. 

PERFORMANCE MEASURE: 

1) Probability of accurately 
detennining weapon system 
availability and ready status 

2) Mean time to determine weapon 
system availability and ready status 

Goal: 

Accuracy > 99% 

Mean Time < 5 minutes 


















Requirement _ 

1.3.4.2 Weapon-Target Pairing 

The C2 system shall assign all high 
priority targets to at least one 
engagement system. _ 

1.3.4.3 Pairing Timeliness 
The C2 system shall complete 
weapon-target pairing within TBD 
seconds after a target has been 
assigned for attack. 

1.3.4.4 Engagement Coordination 
The system shall be able to support 
coordination of engagements with 
other operational nodes and friendly 
forces. 


Rationale 

NT A 
3.1.3.Ml 


NT A 
3.1.3.M2 


Type 

Value System Design 

Architecture Function 

Perfonnance 


3.2.3 Compile Weapon 
Target Pairing Options 

Perfonnance 


3.2.1 Estimate 

Engagement Effectiveness 

3.2.2 Identify Engagement 
Conflicts 

3.2.3 Compile Weapon 
Target Pairing Options 

Functional 

Obj: To determine capability of C2 
to coordinate weapon engagements 
with other platform C2 systems. 

PERFORMANCE MEASURE: 
Percent of surrounding C2 
platforms notified of weapon 
engagement plans. 

Goal: Notified C2 of pending, 
prior, and future engagements > 

X% 

1.3 Display 

Engagement/VBSS Status 
1.5 Display Command 

Data 

3.2.1 Estimate 

Engagement Effectiveness 

3.2.2 Identify Engagement 
Conflicts 

3.2.3 Compile Weapon 
Target Pairing Options 

3.6.1 Develop 

Engagement Guidance 

3.6.2 Develop Sensor 

Plans 
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Requirement _ Rationale Type 

1.3.4.5 Control of Non-Kinetic Stockbauer Functional 

Effectors 2008 

The C2 system shall be able to 

employ non-kinetic effectors, 

including RF weapons, prop-fouling 

devices and ES systems. 


1.3.4.5.1 Non-Kinetic Weapons Functional 
Assignment 

The C2 system shall be able to 
estimate the effectiveness of non- 
kinetic effectors against all tracks and 
present all kinetic and non-kinetic 
effect or options to the operator. 

1.3.4.5.2 Non-Kinetic Weapons Functional 
Control 

The C2 system shall be able to 

control non-kinetic weapons. _ 

1.3.4.6 Use Rules of Engagement NTA 3.1.2 Functional 

The C2 system shall allow for input 

of rules of engagement and anned 

laws of conflict and their use in the 

target selection for attack decision. 


Value System Design _ Architecture Function 

Obj: To determine capability of C2 
to employ non-kinetic effectors. 

PERFORMANCE MEASURE: 

Percent of non-kinetic effectors 
available for use. 

Goal: Available non-kinetic 

effectors for operational use > 99% _ 

Obj: To determine capability of C2 3.2.1 Estimate 

to select best non-kinetic effect or Engagement Effectiveness 

for target 3.2.2 Identify Engagement 

Conflicts 

PERFORMANCE MEASURE: 

Mean time for selected non-kinetic 
effect to impact target. 

Goal: Time <15 minutes _ 

Obj: To determine the capability of 3.3 Issue Engagement 
C2 in utilizing non-kinetic WCS. Order 

Same as 1.3 objectives and 3.1.1 Identify Threats 

Perfonnance measures 3.1.2 Prioritize Threats 

3.1.3 Identify Actions 
Required for Each Threat 

3.3 Issue Engagement 
Order 


























Requirement 

Rationale 

Type 

Value System Design 

Architecture Function 

1.3.5 Develop Order to Fire 

The C2 system shall send a weapon 
fire order instruction to the selected 
platform and weapon system with 
target track parameters, required 
intercept parameters and weapon 
type. 

NTA 3.1.4 

Functional 

Obj: To determine capability of C2 
to develop ‘order to fire’ 

PERFORMANCE MEASURE: 
Completeness of Firing Order 
Instruction. 

Goal: Completeness of firing order 
during operation > 99% 


1.3.5.1 Fire Order Timeliness 

The C2 system shall develop and 
issue an order to fire within TBD 
seconds after the completion of 
weapon-target pairing. 

NT A 

3.1.4.Ml 

Perfonnance 


3.3 Issue Engagement 

Order 

1.3.5.2 Correct Fire Orders 

The C2 system shall correctly prepare 
all fire orders. 

NTA 

3.1.4.M2 

Perfonnance 


3.3 Issue Engagement 

Order 

1.3.5.3 Correct Engagement System 
The C2 system shall issue TBD% of 
fire orders to the correct engagement 
system. 

NTA 

3.1.4.2.M3 

Perfonnance 


3.3 Issue Engagement 

Order 
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Rationale 

NTA 3.1.5 


Requirement _ 

1.3.6 Conduct Tactical Combat 
Assessment 

The C2 system shall assess the 
success of the engagement. 


1.3.6.1 Attack Assessment 
Availability 

The C2 system shall provide combat 
assessment for TBD% of all engaged 
targets. _ 


NTA 
3.1.5.Ml 


Type 

Value System Design 

Architecture Function 

Functional 

Obj: To determine capability of C2 
to complete battle damage 
assessment, complete munitions 
effect assessment, and provide re¬ 
attack recommendations (if 
necessary). 

PERFORMANCE MEASURE: 
Accuracy of battle damage 
assessment. 

Accuracy of munitions effect 
assessment. 

Accuracy of Re-attack 
recommendations. 

Goal: Battle Damage Assessment 
Accuracy > 99% 

Munitions Effect Assessment 
Accuracy > 99% 

Re-attack recommendation 
accuracy > 99% 


Perfonnance 


3.7 Assess Engagement 
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Requirement _ 

1.3.6.2 Attack Assessment 
Timeliness 

The C2 system shall complete 
assessment of attacks within TBD 
minutes. _ 

1.3.6.3 COA Assessment 

The C2 system shall assess the course 
of action upon completion of the 

engagement. _ 

1.4 Information Exchange 
The C2 system shall have the 
capability to exchange information 
with shipboard and national assets. 


Rationale 

NT A 
3.1.5.M3 


NTA 5.1.1, 
SUW & MIO 
Threads 


Type 

Value System Design 

Architecture Function 

Performance 


3.7 Assess Engagement 

Functional 


3.1.2 Prioritize Threats 

3.1.3 Identify Actions 
Required for Each Threat 

Functional 

Obj: Assess C2 capability in 
exchanging information with allied 
participants 

PERFORMANCE MEASURE: 
Evaluate C2 capability in 
exchanging data to necessary 
participants 

Percent of shipboard assets with the 
capability to exchange information 
with C2. 

Percent of national assets with the 
capability to exchange information 
with C2. 

Goal: Shipboard Communication > 
99% 

National Asset Communication > 
99% 
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Requirement 

Rationale 

Type 

Value System Design 

Architecture Function 

1.4.1 Data Format 

The C2 System data format shall be 
compatible with TBD information 
systems as defined in TBD Interface 
requirements documents. 


Functional 

Obj: To determine if C2 data is 
compatible with TBD infonnation 
system. 

PERFORMANCE MEASURE: 
Percent of data fonnat 
compatibility. 

Goal: Data Compatibility among 
systems >85% 

2.1 Store and Report 

Tracks 

2.2 Form Tracks 

3.1.1 Identify Threats 

3.6 Develop Execution 
Guidance 

4 Report Status 
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Requirement _ Rationale 

1.4.2 Data Exchange NTA 5.1.1 

The C2 system shall support 

obtaining, relaying, and distributing 

data and information with service, 

joint, interagency, intra-agency, and 

coalition forces. 


1.4.2.1 Data Exchange Information 
Information shall include mission, 
courses of action, tasking orders, 
operational plans and orders, 
intelligence, environmental 
conditions, friendly unit status and 
location, relaying I&W information. 


Type 

Functional 


Functional 


Value System Design _ Architecture Function 

Obj: To determine capability of C2 2.1 Store and Report 

to exchange infonnation with Tracks 

services, joint interagency, intra- 2.2 Form Tracks 
agency, and coalition forces. 3.1.1 Identify Threats 

3.6 Develop Execution 

PERFORMANCE MEASURE: Guidance 

Percent of data successfully relayed 4 Report Status 
to services, joint interagency, intra¬ 
agency, and coalition forces. 

Percent of data successfully 
obtained from services, joint 
interagency, intra-agency, and 
coalition forces. 

Percent of data successfully 
distributed to services, joint 
interagency, intra-agency, and 
coalition forces 

Goal: Successful relay > 99% 

Successful data acquisition > 99% 

Successful data distribution > 99% _ 

Same as 1.4 objectives and 1.2 Display Track Data 

Performance measures 1.3 Display 

Engagement/VBSS Status 

1.4 Display Sensor Status 

1.5 Display Command 
Data 


















Requirement 


1.4.3 Information Types 
The C2 system shall utilize joint 
communication links to distribute 
data to include mission, intelligence, 
status, and other reports, e.g. courses 
of action, tasking orders, operational 
plans and orders, environmental 
conditions, friendly unit status and 
location, I&W information. 


1.5 Maintain Infonnation and Naval 
Force Status 

The C2 system shall maintain data 
and information for decision making 
and maintaining a tactical picture. 


Rationale 


NT A 5.1.1 


Type 


Functional 


Value System Design 


Architecture Function 


Obj: To determine capability of C2 2.1 Store and Report 


1.5.1 Suitable Display Format 
Decisions delayed because the C2 
data is not presented to the decision 
maker in a suitable fonnat shall not 
exceed 0.01%(threshold), 0.001% 
(objective) 



NT A 
5.1.3.M3 
CPD for 
GCCS-M v4. 


to distribute data via joint 
communication li nk s. 

PERFORMANCE MEASURE: 
Percent of joint communication 
li nk s usable by the C2 system. 

Goal: Usability of Joint 
Communication Links > 85% 


Obj: To determine capability of C2 
to maintain infonnation and Naval 
Force Status 

PERFORMANCE MEASURE: 
Percent of data stored. 

Accuracy of Naval Force status 

Goal: Data storage > 99% 

Accuracy of Naval Force Status > 
85% 


Perfonnance 


Tracks 

2.2 Form Tracks 
3.1.1 Identify Threats 
3.6 Develop Execution 
Guidance 
4 Report Status 




1.1 Provide Tactical 
Display Configuration 
Options 

1.3 Display 

Engagement/VBSS Status 

1.4 Display Sensor Status 

1.5 Display Command 
Data 
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Rationale 


NT A 
5.1.3M1 


Requirement 


1.5.2 System Updates 
(U) The C2 system track file and 
displays shall be updated within 20 
seconds of receiving updated data 


1.5.3 Maintain and Display Tactical NTA5.1.3.1 
Picture 

The C2 system shall maintain and 
display a common tactical picture. 


Type 


Perfonnance 


Value System Design 


1.5.3.1 Tactical Displays 
Operator consoles and displays 
showing tactical picture data shall 
utilize standard symbology. 


1.5.3.2 Track Ambiguity 
The number of unresolved track 
ambiguities shall not exceed TBD per 
24 hour period. 


NT A 

5.1.3.1.M1 




Perfonnance 


Architecture Function 


1.2 Display Track Data 

2.2 Form Tracks 


Obj: Assess C2 capability to 
maintain and display a tactical 
picture. 

PERFORMANCE MEASURE: 
Evaluate C2 capability in 
maintaining a common tactical 
picture with all participants. 

Goal: Meantime in C2 exchange of 
messages < 30 seconds 


Obj: Assess C2 capability in 
displaying battle space picture to 
operators 

PERFORMANCE MEASURE: 
Evaluate C2 functionality in 
displaying information on the battle 
space to operators 

Goal: Meantime in C2 exchange of 
messages < 30 seconds_ 



1.3 Display 

Engagement/VBSS Status 

1.4 Display Sensor Status 

1.5 Display Command 
Data 



2.5 Correlate/Decorrelate 
Tracks 
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Requirement 

Rationale 

Type 

1.5.3.3 Dual Tracks 

The percentage of dual tracks shall 
never exceed TBD% of all tracks 
displayed. 

NT A 

5.1.3.1.M2 

Perfonnance 

1.5.3.4 Track Number Consistency 
The number of non-constant track 
numbers shall not exceed TBD per 24 
hour period. 

NT A 

5.1.3.1.M3 

Perfonnance 

1.5.3.5 Tactical Picture 

The C2 system shall meet the 
following performance requirements. 

Stockbauer 

2008 

Perfonnance 

1.5.3.5.1 Ambiguous Tracks 

The C2 system shall hold only a 
single track for each surface object 
for at least TBD percent of all surface 
contacts. 

SIAP 

Perfonnance 

1.5.3.5.2 Continuity 

The C2 system shall have fewer than 
TBD track number changes per 
surface contact during tracks life. 

SIAP 

Perfonnance 

1.5.3.5.3 Track Consistency 

The C2 system shall maintain a 
consistent track number, identity and 
kinematic data with Link-16 tracks 
for TBD percent of tracks. 

SIAP 

Perfonnance 
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System Design _ Architecture Function 

2.5 Correlate/Decorrelate 
Tracks 



2.5 Correlate/Decorrelate 
Tracks 


2.7 Manage Track 
Numbers 


2.5 Correlate/Decorrelate 
Tracks 

2.7 Manage Track 
Numbers 
































Requirement 

Rationale 

1.5.4 Maintain and Display Force 
Command and Coordination Status 
Operator consoles and tactical 
displays shall permit display of 
detailed data of own-force units, 
including unit ID, task organization 
and mission assignment. 

NTA 5.1.3.2 

1.5.5 Maintain and Display Unit 
Readiness 

Operator consoles and tactical 
displays shall permit display of 
detailed data of own-force units, 
including unit readiness, mission 
capability, weapon status, and fuel 
state. 

NTA5.1.3.3 


Type 


Functional 



Value System Design 

Architecture Function 

Obj: Assess C2 capability to 
maintain and display a tactical 
picture. 

PERFORMANCE MEASURE: 
Evaluate C2 capability in 
maintaining a common tactical 
picture with all participants. 

Goal: Meantime in C2 exchange of 
messages < 30 seconds 

1.5 Display Command 

Data 

Obj: Assess C2 capability to 
maintain and display a tactical 
picture. 

PERFORMANCE MEASURE: 
Evaluate C2 capability in 
maintaining a common tactical 
picture with all participants. 

Goal: Meantime in C2 exchange of 
messages < 30 seconds 

1.4 Display Sensor Status 



















Requirement _ Rationale Type 

1.6 Analyze and Assess NT A 5.2.1 Functional 

The C2 system shall provide the 

commander with tactical situational 

awareness data; friendly force ID, 

task organization, task assignment, 

and readiness data; automated access 

to reference threat and intelligence 

data, decision aids and optask 

reference information suitable for 

effective command and control of 

assigned units. 


1.6.1 Tailor-able Display Functional 

The system shall provide the ability 

for the user to tailor the display. _ 

1.6.2 Situational Awareness TDAs Functional 

The C2 system shall display 

situational awareness information to 
decision makers using tactical 
decision aids (TDAs). 


Value System Design _ Architecture Function 

Obj: Detennine if C2 effectively 
communicates and transfers data 
and situational awareness to 
participants and commanders 

PERFORMANCE MEASURE: 

Evaluate C2 effectiveness in 
communicated and displayed 
information regarding the situation, 
contacts, assets, and threats to 
participants and commanders. 

Goal: Meantime in C2 exchange of 

messages < 30 seconds _ 

1.1 Provide Tactical 
Display Configuration 

_ Options _ 

Obj: Evaluate C2 capability in 1.3 Display 
maintaining a common tactical Engagement/VBSS Status 

picture with all participants. 1.4 Display Sensor Status 

1.5 Display Command 
PERFORMANCE MEASURE: Data 

Evaluate C2 capability in 
maintaining a common tactical 
picture with all participants. 

Goal: Meantime in C2 exchange of 

messages < 30 seconds _ 


















Requirement _ Rationale Type _ Value System Design _ Architecture Function 

1.6.3 Apply Rules of Engagement NTA5.2.1.3; Functional Obj: Assess C2 capability in 3.6.1 Develop 

(ROE) SUW and effectively applying ROE Engagement Guidance 

The C2 system shall apply rules of MIO threads 

engagement (ROE) to all developed PERFORMANCE MEASURE: 

plans and recommendations. Evaluated C2 effectiveness in 

applying ROE. 

Goal: Meantime in C2 exchange of 

_ engagement messages < 30 seconds _ 

1.6.4 Develop Courses of Action NTA 5.3.3, Functional Obj: Assess C2 capability in COAs 

(COA) SUW & MIO in response to mission needs, 

The C2 system shall develop courses threads environment, and contacts, 

of action (COAs). 

PERFORMANCE MEASURE: 

Evaluate C2 response to mission 
needs, environment, and contacts 
via C2 COAs. 

Goal: Meantime for C2 to develop 

_ a COA < 5 mins. _ 

1.6.4.1 COA Recommendations NTA Perfonnance 3.1.3 Identify Actions 

The C2 system shall recommend a 5.3.3.M3 Required for Each Threat 

minimum of TBD COAs per tactical 
action. 
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Requirement 

Rationale 

Type 

Value System Design 

Architecture Function 

1.6.4.2 COA Recommendation 
Ranking 

The C2 TDAs shall pennit ranking of 
COA recommendations in order of 
assessed probability of success, 
confidence level, or other relevant 
performance measure. 


Functional 

Obj: Assess C2 capability in COAs 
in response to mission needs, 
environment, and contacts. 

PERFORMANCE MEASURE: 
Evaluate C2 response to mission 
needs, environment, and contacts 
via C2 COAs. 

Goal: Meantime for C2 to develop 
a COA < 5 mins. 

3.2.3 Compile Weapon 
Target Pairing Options 

1.6.4.3 COA TDAs 

The C2 system shall display 
recommended COAs to decision 
makers using tactical decision aids 
(TDAs). 


Functional 

Obj: Assess C2 capability in COAs 
in response to mission needs, 
environment, and contacts. 

PERFORMANCE MEASURE: 
Evaluate C2 response to mission 
needs, environment, and contacts 
via C2 COAs. 

Goal: Meantime for C2 to develop 
a COA < 5 mins. 
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Requirement 

Rationale 

Type 

Value System Design 

Architecture Function 

1.7 Develop Search Plan 

The C2 system shall develop surface 
search plans. 

SUW & MIO 
threads, NTA 
5.3.3 

Functional 

Obj: Determine C2 ability to 
develop a search plan in a dynamic 
environment 

PERFORMANCE MEASURE: 
Evaluate the ability of C2 to 
develop search plan to dynamic 
environments 

Goal: Meantime for C2 to develop 
a search plan < 5 mins. 


1.7.1 Types of Search Plans 

The C2 system shall be capable of 
developing area and directed search 
plans. 

NWP 3-20 

Functional 

Obj: Determine C2 ability to 
develop a search plan in a dynamic 
environment 

PERFORMANCE MEASURE: 
Evaluate the ability of C2 to 
develop search plan to dynamic 
environments 

Goal: Meantime C2 takes to initiate 
a search plan <10 seconds 
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Requirement 


1.7.1.1 Search Plan Factors 
The C2 system shall have the 
capability to process the following 
information when developing search 
plans: 

1. Prior surveillance (leverage 
COP/CTP information) 

2. Historical operating pattern 

3. Platform endurance and range 

4. Weapons and sensor capabilities 

5. Size of the area and threat axis 

6. Search priorities 

7. Environmental factors 

8. Shipping density._ 


1.7.2 Control Sensors 
The C2 system shall be able to direct 
sensors according to the approved 
search plan. 


Rationale 


NWP 3-20 


Type 





SUW&MIO Functional 
threads 


Value System Design Architecture Function 


Obj: Determine C2 ability to 3.6.2 Develop Sensor 

develop a search plan in a dynamic Plans 
environment 

PERFORMANCE MEASURE: 

Evaluate the ability of C2 to 
develop search plan to dynamic 
environments 

Goal: Meantime C2 takes to initiate 
a search plan < X seconds 


Obj: Determine C2 capability in 
directing sensor systems in an 
approved search plan 

PERFORMANCE MEASURE: 
Evaluate C2 ability in directing 
sensor systems 


3.6.2 Develop Sensor 
Plans 


Goal: Meantime C2 takes in 
sending a message to direct sensors 
<10 seconds 


1.7.3 Plan Suitability NTA Perfonnance 

100% of search plans developed by 5.3.3.Ml 

the C2 system shall be achievable. 


1.7.4 Plan Timeliness NTA Perfonnance 

The C2 system shall develop a search 5.3.3.M2 
plan within 30 minutes. 



3.6.2 Develop Sensor 
Plans 


3.6.2 Develop Sensor 
Plans 
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Requirement 

Rationale 

1.7.5 Alternative Plans 

The C2 system shall develop TBD# 
of alternative search plans. 

NT A 

5.3.3.M3 

1.8 Constraint Requirements 


1.8.1 Lifecycle Impacts 

The C2 system shall satisfy the 
following life cycle requirements. 

Stockbauer 

2008 

1.8.1.1 CRUDES Manning 

The C2 system shall not increase the 
manning requirements on any Navy 
ships. 

Stockbauer 

2008 

1.8.1.2 Training Costs 

The C2 system shall not increase the 
cost to train the operators of the C2 
system. 

Stockbauer 

2008 

1.8.1.3 Support Costs 

The C2 system shall not increase the 
cost to support the C2 system post¬ 
installation. 

Stockbauer 

2008 

1.8.1.4 Operational Availability 

The C2 system shall have an 
operational availability of at least 
TBD%. 

Goddin 2008 


Type 

Value System Design 

Architecture Function 

Perfonnance 


3.6.2 Develop Sensor 

Plans 

Constraint 



Constraint 



Constraint 

The C2 system shall not increase 
the manning requirements on any 
Navy surface combatants. 

Obj: To maintain or decrease 
current manning levels for C2 
system operation 

PERFORMANCE MEASURE: 
Manning levels required for 
operation 


Constraint 

The C2 system shall not increase 
the cost to train the operators of the 
C2 system. 


Constraint 

The C2 system shall not increase 
the cost to support the C2 system 
post-installation. 


Constraint 

The C2 system shall have an 
operational availability of at least 
TBD%. 
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Requirement _ Rationale Type 

1.8.1.4.1 MTBF Constraint 
The C2 system shall have a Mean 

Time Between Critical Failures of 

greater than TBD hours. _ 

1.8.1.4.2 Mean Down Time Constraint 
The C2 system shall have a Mean 

Down Time of less than TBD hours. _ 

1.8.2 MOSA Design USD Constraint 

The C2 system shall implement a (AT&L), 

MOSA design, while maintaining the "The Defense 
independence of the application from Acquisition 
the underlying computing plant. System", 

2003; 

Stockbauer 

_ 2008 _ 

1.8.3 DISR Technical Standards Stockbauer Constraint 

The C2 system shall only implement 2008 

standards found in the Defense 
Information Systems Repository 

(DISR). _ 

1.8.4 Net-Ready KPPs CJCSI Constraint 

The C2 system shall be compliant 6212.0IE 

with the Net-Ready Key Performance 

Parameter as listed in the table below. _ 

1.8.5 Cost KPP Constraint 

The C2 system cost shall not exceed 

$TBD. 


Architecture Function 


Value System Design _ 

The C2 system shall have a Mean 
Time Between Critical Failures of 
greater than TBD hours. 


The C2 system shall have a Mean 
Down Time of less than TBD 

hours. _ 

The C2 system shall implement a 
MOSA design, while maintaining 
the independence of the application 
from the underlying computing 
plant. 


The C2 system shall only 
implement standards found in the 
Defense Information Systems 
Repository (DISR). 


The C2 system shall be compliant 
with the Net-Ready Key 
Perfonnance Parameter as listed in 

the table below. _ 

The C2 system cost shall not 
exceed $TBD. 
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APPENDIX D: ADDITIONAL CORESIM MODEL VIEWS 


Figures 38-41 are the Enhanced Functional Flow Block Diagrams (EFFBD) for the C2 
Architecture Operational Activities. The first diagram is the same as Figure 28 in the body of the 
report. It represents the top-level view. The next three diagrams represent the second tier of the 
operational activities, including Figure 29 from the body of the report. 



Figure 38: EFFBD of Top-Level C2 Operational Activities 


This EFFBD displays the top-level operational activities, all executed in parallel, with iteration to 
support multiple successive targets 
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1.1 _ 

Track Contacts 


Track Files 



L3_ 

Identify Contacts 


Figure 39: Collect Target Information C2 Operational Activities 

This EFFBD is the decomposition of the “Collect Target Information” Operational Activity. 
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▼ 

AND 


N Develop Order to H 
Fire 


2.5 _ 

Conduct Tactical 
Combat 
Assessment 


OR 


Figure 40: Target Processing C2 Operational Activities 


This EFFBD is the decomposition of the “Process Targets” Operational Activity. The top branch 
includes activities associated with the SUW mission. The bottom branch shows the activity 
associated with the MIO. 
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3.1 


Maintain and 

Display Tactical 
Picture 

** 


/ % 


Track Files 


Link 

Settings 


Track File 
Update 



3.2 _ 

Maintain and 
► Display Force 
Command and 
Coordination St... 



3.3 


Maintain and 

Display Unit 
Readiness 



Figure 41: Maintain Information and Naval Force Status C2 Operational 
Activities 


This EFFBD displays the “Maintain Information and Naval Force Status” C2 Operational 
Activities. 


Figures 42-45 are the Enhanced Functional Flow Block Diagrams (EFFBD) for the C2 
Architecture System Functions. The first diagram is the same as Figure 31 in the body of the 
report. It represents the top-level view. The next three diagrams represent the second tier of the 
system functions, including Figure 32 from the body of the report. 
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Figure 42: EFFBD of Top-Level C2 System Functions 

This figure shows the top-level system functions as an EFFBD, where each function is executed in 
parallel to support multiple targets. 
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Track VBSS / 

Display C... Engagem... 


Sensor 
Status Dis... 



Figure 43: Display Tactical Data C2 Functions 

This EFFBD displays the sub-functions of the “Display Tactical Data” system function. 
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Figure 44: Perform Track Management C2 Functions 


This EFFBD displays the sub-functions that compose the “Perform Track Management” system 
function. 
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"37i 

SUW Mission Thread . 

Assess and 

To * 

Prioritize Threats 




'3.2 


Determine 
Weapon Target 
Pairing Options 


3.3 


Issue 

Engagement 

Order 



Track Files 


* 



3.4 


3.5 

MIO Mission Thread . 


► 

Issue Boarding 
Order 

To * 

Query Ship 



^6 


3.7 

Develop 

Execution 

Guidance 

► 

Assess 

Engagement 


Figure 45: Conduct Combat Control C2 Functions 


This figure shows the child functions of the Conduct Combat Control function. The separate 
branches show the functions associated with the SUW and MIO missions. 
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APPENDIX E: ACRONYM LIST 


Acronym 

Term 

AIS 

Automatic Identification System 

ASCM 

Anti-Ship Cruise Missile 

C2 

Command and Control 

C3 

Command, Control and Communications 

C4I 

Command, Control, Communications, Computers, Intelligence 

CBN 

Chemical, Biological and Nuclear 

CG 

Guided Missile Cruiser 

COC 

Combat Operations Center 

COP 

Common Operational Picture 

COTS 

Commercial-Off-The-Shelf 

CPN 

Colored Petri Nets 

CSCS 

Center for Surface Combat Systems 

CSG 

Carrier Strike Group 

CTP 

Common Tactical Picture 

DAS 

Defense Acquisition System 

DCO 

Defense Connect Online 

DDG 

Guided Missile Destroyer 

DISR 

Department of Defense Information Technology Standards 

Repository 

DoDAF 

Department of Defense Architecture Framework 

DOORS 

Dynamic Object Oriented Requirements System 

DWC 

Distributed Weapons Coordination 

EO/IR 

Electro-Optical/Infra-Red 

EOR 

Engage on Remote 

ER&A 

Enterprise Requirements and Architecture 

EFFBD 

Extended Functional Flow Block Diagram 

ES 

Electronic Support 

EW 

Electronic Warfare 

FAC 

Fast Attack Craft 

FFG 

Guided Missile Frigate 

FIAC 

Fast Inshore Attack Craft 

GPS IS 

Global Positioning System Interface Specification 

I&W 

Indications & Warnings 

ICOMS 

Inputs, Controls, Outputs, and Mechanisms 

IDEFO 

Integration Definition language 0 

IED 

Improvised Explosive Devices 

IFF 

Identification Friend or Foe 

IPR 

Integrated Product Review 

IPT 

Integrated Product Team 

ISR 

Intelligence, Surveillance and Reconnaissance 

IWS 

Integrated Warfare Systems 
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Acronym 

Term 

JCIDS 

Joint Capabilities Integration and Development System 

JIC 

Joint Integrating Concepts 

JFC 

Joint Functional Concepts 

LNG 

Liquid Natural Gas 

M&S 

Modeling & Simulation 

MBSE 

Model-Based Systems Engineering 

MIC 

Maritime Intercept Commander 

MIO 

Maritime Interception Operations 

MMSI 

Maritime Mobile Service Identity 

MOSA 

Modular Open Systems Architecture 

MSSE 

Masters of Science in Systems Engineering 

MT 

Message Type 

NOC 

Naval Operating Concept 

NPS 

Naval Postgraduate School 

NSWC 

Naval Surface Warfare Center 

NSWM 

Navy Surface Warfare Manual 

NT A 

Navy Tactical Task 

NTTL 

Navy Tactical Task List 

NTTP 

Naval Tactics, Techniques and Procedures 

NWP 

Naval Warfare Publication 

ONI 

Office of Naval Intelligence 

OSC 

On Scene Commander 

OTH 

Over-the-Horizon 

OV 

Operational View 

PEO 

Program Executive Office 

PLAN 

People’s Liberation Army Navy 

PMP 

Project Management Plan 

POA&M 

Plan of Action & Milestones 

PPBES 

Planning, Programming, Budgeting, and Execution System 

PPR 

Pre-planned Response 

RCS 

Radar Cross Section 

RF 

Radio Frequency 

ROE 

Rules of Engagement 

ROV 

Remotely Operated Vehicle 

RPG 

Rocket Propelled Grenade 

SAG 

Surface Action Group 

SAM 

Surface-to-Air Missile 

see 

Strongly Connected Components 

SE 

Systems Engineering 

SEDP 

Systems Engineering Design Process 

SIAP 

Single Integrated Air Picture 

SITREP 

Situation Report 

SLOC 

Sea Line of Communication 

SSDS 

Ship Self-Defense System 
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Acronym 

Term 

SSM 

Surface-to-Surface Missile 

suw 

Surface Warfare 

suwc 

Surface Warfare Commander 

sv 

Standard View 

TA 

Technical Assistant 

TBD 

To Be Determined 

TEU 

Twenty-foot Equivalent Units 

UP 

Tactics, Techniques, and Procedures 

TV 

Technical View 

UAV 

Unmanned Aerial Vehicle 

USV 

Unmanned Surface Vehicle 

LJNTL 

Universal Naval Task List 

VAMOSC 

Visibility and Management of Operating and Support Cost 

VBSS 

Visit, Board, Search and Seizure 

VHF 

Very High Frequency 

VSD 

Value System Design 

WMD 

Weapons of Mass Destruction 
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